Page 1 of 1

VS1010 feature questions

Posted: Fri 2020-10-09 21:42
by joe6486
I'm just becoming acquainted with the VS1010, and am exploring the minidemo. I have a few questions -

1. CONFIG.TXT only runs automatically from the sdcard, and not the internal SPI flash, correct? Is there a way to run it automatically from internal SPI flash upon booting? I suppose f:sys/boot.dlx could serve a similar purpose.

2. The system crashes/hangs if the sdcard is removed during playback. Is there a good way to make the system more resilient? We have to assume customers will remove the card and will expect the system to recover. We'd like the console to continue accepting commands when the card is removed, and resume (or restart) playback when the card is re-inserted. When the card is re-inserted, instead we get a "Read Error". I would think this error should occur soon after the card is removed? A reboot on card removal would be ok I think.

3. It would be nice if we could use the VS1010 as a USB dongle (for feeding through serial commands to the host system) as well as a playback device (SPI + sdcard), at the same time. Has this been explored?

4. When starting with a SD card plugged in, it automatically loops all the tracks on the sdcard, which is good, but then it continues playing any sound files in the f: directory. Is there a simple way to prevent this, but have the f: tracks be available for selective playback?

Thanks for the help!

Re: VS1010 feature questions

Posted: Thu 2020-10-15 15:29
by joe6486
Hi, is anyone able to answer these questions?

Re: VS1010 feature questions

Posted: Thu 2020-10-15 21:15
by Panu

Sorry, I missed your message earlier. Strange that it did not show up in my list of new topics.

Do you have the VS1010 handbook? The boot process is explained there in more detail.

1) If you format the flash to FAT and put a SYS folder there, then the flash becomes the system disk S: instead of the SD card.

2,4) You seem to be running the very simple player routine which is in the ROM. That one plays D: root and then F: root. It's mainly good for testing the chip, nice to get some sound out of the IC without writing player firmware. The book has some discussion about how to do player firmware. But the easy way of getting rid of F: is to change the F: drive letter. For this you need to write a small program that has just a couple of lines; e.g. VODEV('M') = VODEV('F'); to make M: disk what the F: disk was. Then set the F: disk to point to somewhere else, or to NULL (no device), e.g. VODEV('F'') = NULL; Then when the player plays from F: it will not find anything, but you can play those files from disk M:

3) Hmm, tricky due to CPU clock requirements and no multitasking. But if you reboot the device into runlevel 8 (REBOOT 8 on the command line), then it becomes a USB UART device which shows the command line to the USB UART. From the command line you can give commands. Works in OSes that recognize USB CDC class devices (Linux, Win10, Mac) but the ROM implementation of CDC is less than perfect, leading to high CPU load on the PC for example. But it's good enough for bringing up the system and debugging. Again, custom firmware makes things better. We even have some at our website, please see our USB UART demoboard.


Re: VS1010 feature questions

Posted: Wed 2020-10-21 18:43
by joe6486
Thanks! I also did not receive a notification of your response.

I do have the book and am aware of the booting procedure. I had incorrectly assumed that the config.txt should be in the f:\sys folder rather than root, that was the issue. Thanks for clearing that up.

I am surprised to hear that the included code is described as for testing only, just to get some sound from a chip? One of the nice features is that there is minimal development necessary to make a workable playback system; I would hope to stay with included routines, I figured the ROM programs are the real workhorse. Perhaps I misunderstood.

That the system is completely frozen upon sdcard removal seems to be a clear bug to me. It appears that the ROM-based "play" command does not contain a timeout of other abort if the file is no longer available. This is probably something rather difficult for a designer like me to fix, as it is within the special ROM routines.

Luckily, I believe I have a simple hardware fix: The minidemo uses the sd detection to turn on the 3.3V regulator, which powers the sdcard and provides a pullup voltage for the DI and DO pins. When the card is removed, these pins are no longer pulled up, leading to the player hanging. I would recommend changing the source of this pullup to another 3.3V source, such as AVDD, or, better, tying the EN pin high on U2 permanently. I might also recommend connecting the detection to GPIO, though I suppose it's easy enough to see if there's a s: drive.

This seems to solve it - if the sdcard is removed the system reports an error correctly and continues on, and responds to console commands. If it is reinserted (without activating the console) it restarts playing from the beginning. Perfect! I would highly recommend this change to a future revision, unless there were some consequences I'm not aware of.

Another much simpler solution to (4) I got lucky with as well:

I put the internal sound files in the f:/sys directory (which is also s:/sys). It seems that the default player doesn't play these files after finishing what's on the sd card, which is great. But I can of course still play files selectively from here using the usual "play" command. Exactly what I wanted, and no need to even install VSIDE. :)

Oh - also the link to the schematic 2.3 on the minidemo product page points to 1.2 incorrectly, it should go to ... 23_sch.pdf

A couple of additional questions -

I didn't see any documentation of VODEV command in the book, but I could have overlooked it. Are there more resources for things like this?

I'd also like to get a list of all of the internal ROM commands; I can see the ones listed in s:\, but are there others, besides "play"?

Is there a simple/clever way to play a file, or directory, in a loop, from the console? Or a quick and easy dlx that does this?

Thanks for the support!

Re: VS1010 feature questions

Posted: Thu 2020-10-22 9:59
by Hannu
Well the ROM code is minimal in the sense providing some sane starting points and provides subset of things which are just enough to program the device, but for fully featured product, some software is needed. Also sometimes the ROM code does exactly opposite things as you would like it to do. Fortunately it is so easy to get your own code to work with the ROM.

The SD card regulator enable pin is working in two ways. First it provides working reset for SD card. If card is stuck, only way to reset is to power cycle it. Second it provides card detection. If the pull-ups are from IOVDD, the card can get poorly powered through them (and do undefined things) fortunately if SD interface is in GPIO mode and driven low, it should power cycle properly. ROM has hook ResetExternalUnit which could do this. The another is card detection which as far as I know isn't used. I'll give more serious though on this pull-up issue. Thanks for report.

VODEV() macro is in the vsos.h file. CTRL-shift-F in VSIDE and library find is your best friend. And the ROM sources are also very nice source of information. Showing how the device drivers work and how the pointers are set up and so on.

You can see programs with

Code: Select all

dir r: 
and there are two special cases in main.c of the rom code. "exit" and "play"

Re: VS1010 feature questions

Posted: Thu 2020-10-22 14:32
by joe6486
Got it, thanks. I'll spend some time this weekend exploring the ROM and other internals. I'm so close to what we need without any custom software anyway but I am intrigued by future possibilities with this chip.

In the case of the sdcard getting stuck, I've only seen it freeze the system, so there is no knowledge of the problem, and no opportunity to call the ResetExternalUnit routine automatically. I recall that IOVDD doesn't source enough current to drive the sdcard reliably (maybe during write), so that's probably the main purpose of the regulator. (Also in case IOVDD is 1.8V)

I'm just guessing, but if the EN pin was always high (tied to VHIGH), and the pullups are sourced from the regulator's 3V3, this would be reliable as long as the chip was always powered (which is the case for minidemo). If it was powered down by somehow removing VHIGH from the chip, but leaving 3V3, the chip could partially power through these pullups with unpredictable results. Pullup to IOVDD should also be fine as long as it wasn't ever configured to 1.8V.

So for a design that is essentially identical to minidemo, pulling the EN high permanently should ensure reliable operation, would you agree? (This is what I intend for my design, that's why I'm checking).

Re: VS1010 feature questions

Posted: Fri 2020-10-23 7:39
by Hannu
I can't see any big problems with that design. Mostly that regulator is always on. And you can put the pull-ups to IOVDD. The total power off can be achieved by software driving the pins low in the power hook.

Pull-ups won't be too hard load for IOVDD. Powering SD card is.

What kind of user interface you are planning? There are next and play/pause buttons in rom. See romplayer.c and if you write software , you can add your own player calllback to do those things.

Re: VS1010 feature questions

Posted: Fri 2020-10-23 15:03
by joe6486
Thank you. This will be purely UART control by a host microcontroller for this design. I have accommodation for full powerdown by just removing the 5V feed elsewhere, so that's probably the most definitive way (though I have to use care that data pins are not held high by something elsewhere, like the I2S host or UART).

Speaking of, is there a simple/clever way to loop a track or directory? "play" just plays one or a set then finishes.