Checklist of common "Getting started" problems (VS10xx+MCU)

[Panu]

- First check that you are doing more or less what it says in our VS1001k FAQ item "So what exactly do I have to do to play a song?" (quoted below).

This is a quote from an old VS1001k FAQ item. Note that VS1001k did not have NEW_MODE which is the recommended bus mode for our more modern chips such as VS1003 and VS1053.

* If hardware reset (pin XRESET) is active, deactivate it. Wait for at least 1 millisecond.

* Activate software reset (bit SM_RESET in SCI register MODE).

* Wait for at least 5 microseconds.

* Read the DREQ pin and wait until it has activated. If activation seems to take more than 1 millisecond, activate hardware reset (pin XRESET), wait at least 1 microsecond, and go back to square one.

* Set all the SCI registers you want to: MODE, VOL, CLOCKF, etc.

* Send at least one (preferably two) byte containing zero to SDI.

* Send the MP3 file to SDI.

* Send 2048 bytes containing zero to SDI (respect the DREQ pin just as with MP3 data).
Note: for VS1053, please use endFillByte instead of zero. See instructions in the datasheet

* Wait 50 milliseconds to make it absolutely sure that audio buffers have been cleared even if the sample rate is only 8 kHz. (Usually this step doesn't need to be implemented.)

* For the next MP3 file, go back to 1.

- See that power, crystal and reset signals are at valid states.

- Check that you don't have unconnected GPIO's in the VS10xx, and that the TEST and RX pins are pulled high. All GPIO pins should be pulled low (or in some cases high to activate functions). For VS1053 it is important that GPIO1 is pulled low. Otherwise VS1053 starts as a midi synthesizer, and won't accept normal commands as in the "normal" mode.

- Select NEW_MODE if it's possible. Don't set "SHARED MODE" if you can connect both XCS and XDCS to your microcontoller. To set NEW_MODE and allow tests, write 0x0820 to the MODE register.

I know the name "shared_mode" is confusing. The "shared" means that SCI and SDI share the same chip select pin XCS on the VS10xx: SCI is activated when XCS=0 and SDI is activated when XCS=1. If the chip select is not shared, then SCI and SDI have separate chip select pins (XCS and XDCS). Then they can be both disabled at the same time (XCS = 1, XDCS = 1) and you can then use the SPI bus for communicating with other devices.

- Be very careful with the chip select signals!

- Check that XCS and XDCS are never both "0" at the same time.

- Check that your chip select signals remain low until the end of the last bit of the last byte of the transmission.

- Measure XCS, XDCS, SCK, MOSI and DREQ signals with your oscilloscope.

- Check that when DREQ is physically high/low (pull up and down the signals on the PCB) that your microcontroller can reliably read these. If not, check your microcontrollers GPIO states (data direction, gpio/periph mode, pullup/pulldown). If you use a #define macro to read the DREQ state, check that it really works (enough parentheses...), a malformed macro might not work correctly and has caused problems in the past.

- Start by sending the Sine Test sequence with ALLOW_TESTS bit set in the MODE register.

- Verify that GBUF/CBUF signal is at 1.25 volts.

- Verify that you can hear a beep.

• Note that for the VOLUME register: 0x0000 is Full Volume, 0x0606 is -3dB, 0xfefe is No sound and 0xffff is Analog Off. Default is 0x0000 (Full Volume).

- Then send an MP3 file, just as you would send the sine test sequence. At this point you should hear music. If it plays at the wrong speed, check CLOCKF register value. If it is choppy or noisy, double check the XCS/XDCS signals. Also check the SPI bus speed. It should be less than 1/4 (less than 1/6 for reading) of the chip clock.

- The chip resets in 1X clock speed. It's not enough to play MP3 at full speed (you will hear music but it has gaps), so setting the CLOCKF register is required. You should check the datasheet for calculating a good CLOCKF value for your crystal and MHz requirement, but if you use 12.288 MHz crystal, you can use for example these CLOCKF values:

• 0x9000 or 0x8800 (3.5+1.0X) for VS1053
• 0xB3FE (3.5+0.5X) for VS1003
• 0x9800 for VS1011

- Check SPI Clock phase and polarity. (Please test all 4 combinations of Clock phase and Clock polarity in the SPI hardware settings of your microcontroller. A wrong mode might cause all or most of data transfers to fail, or in some cases for example make the SPI bus only 99% reliable instead of 100%).

- Note that after reset, before you set the CLOCKF register clock doubler/multiplier, the SPI bus speed must be less than 1/6 of your crystal clock. That's 2 Mbits/s for the default crystal.

- If use a SD library or some other code using the same SPI port, check that the speed stays below CLKI/7 (for SCI reads) and CLKI/4 (for writes) even after using those functions.

See also: Making new designs work with VS1011 / VS10xx

See Henrik's MCU example code at: http://www.vlsi.fi/fileadmin/app_notes/ ... layrec.zip

For an example schematic and some software about connecting VS10x3 to a microcontroller, you can see the information of our (now discontinued) VS1053 Evaluation Kit:
http://www.vlsi.fi/fi/support/evaluatio ... onkit.html
http://www.vlsi.fi/fileadmin/evaluation ... 43_sch.pdf
http://www.vlsi.fi/player_vs1011_1002_1 ... larplayer/

[Panu]

Microchip recommends 180 ohm series resistors on the SPI lines with some PIC microcontrollers.

[Panu]

Some SparkFun VS1053 Breakout Boards have a floating TEST pin, which leads to decode problems and irregular behaviour of DREQ signal, see: viewtopic.php?f=10&t=71. Please also check your GPIO pull-downs and XRESET pull-up with these boards.

[PJMonty]

Thanks for providing this clearing house of suggested things to look for when bringing up a project using the VS MP3 chips. However, I have a couple of questions.

1 - Why do you suggest not using the shared mode of chip select? Is it not reliable?

2 - Why do the GPIO pins need to be pulled low?

Thanks,
PeterM

[Panu]

Hi, and thanks for your great message!

1 - Why do you suggest not using the shared mode of chip select? Is it not reliable?

It's because we have noticed that the shared mode seems to suggest that it means that the SPI bus could be shared between different peripherals, such as the VS10xx, SD card, Display etc... when in fact it's the exact opposite. SHARED_MODE uses the same XCS pin shared for control and data; so one of those is always selected on the SPI bus - preventing to connect other peripherals on the bus.
We've had a lot of confusion about this

The Shared mode is 100% reliable. And below is a super trick that you can use if you are a real power user, but don't tell anyone about this :
With a little creativity, you can use shared_mode to save MCU pins even if you do have extra perips on the bus: 1) pull XCS low to select the SCI (Serial Control Interface). 2) Write SHARED_MODE to MODE register. 3) pull XCS high. Now the chip is in shared_mode and XCS is high so the SDI (Serial Data Interface) is selected on bus. 4) Send MP3 bytes, remembering to obey DREQ as usual. 5) pull XCS low to select the SCI again. 6) write NEW_MODE to MODE register to disable the shared_mode. 7) pull XCS back high to deselect VS10XX from the bus. The bus is now free for communication with other chips such as the SD card.

2 - Why do the GPIO pins need to be pulled low?

We have chosen to use a very reliable CMOS technology to implement the chips. In this technology, input pins really are just that - input pins - and not something that is a "sort of an input pin" but the chip also pushes or pulls some current into or from it. Plain input pins are easy to characterize and test to guarantee the proper operation of the IC. But the downside is that since there is nothing to drive ("bias") the input pins high or low, they tend to float somewhere in between by themselves. Now, this is a bad thing, since it triggers the input pad transistors to conduct randomly towards IOVDD or GND or both, and this causes extra power consumption (up to several mA per pin) and is generally a bad thing. So we really require the user to pull unused pins low (TEST and RX high) on the PCB. You can use a single resistor to pull all unused GPIO[7:0] pins low. Be sure to use a separate pull-up on the TEST pin or connect TEST directly to IOVDD.

-Panu

[Simon]

- Be very careful with the chip select signals!
- Check that xCS and xDCS are never both "0" at the same time.

Hi, Panu.

Could you, please, be more specific describing this circumstance. What will this state (xCS and xDCS are both "0" simultaneously) lead to? Could it damage the VS-chip or just will lead to malfunctioning of it?

E.g., if after [watchdog-]reset of master MCU both lines will be low for some time (until GPIO-setup procedure ends) what consequences this will lead to?

* If hardware reset (pin XRESET) is active, deactivate it. Wait for at least 1 millisecond.
* Activate software reset (bit SM_RESET in SCI register MODE).
...
* Send the MP3 file to SDI.
...
* For the next MP3 file, go back to 1.

Is it necessary to s/w-reset VS-chip before sending every next MP3-file?

[Panu]

Hi!

Could you, please, be more specific describing this circumstance. What will this state (xCS and xDCS are both "0" simultaneously) lead to? Could it damage the VS-chip or just will lead to malfunctioning of it?

It can cause failed register reads/writes and/or glitches in audio, nothing fatal. The worst thing that happens is general confusion for you as the programmer as to what's going on when the chip seems to behave irrationally..

Is it necessary to s/w-reset VS-chip before sending every next MP3-file?

If the files don't have errors, and you send the entire file, then it's not...

Actually, MP3 is a very robust format (as it was designed for satellite radio transmission, you know) so MP3 can recover from just about any failure in the stream. But other more complex formats like WMA, AAC or Vorbis can get more confused from bit errors in the stream. With those it's especially helpful to set a known state in the decoder (using software reset) so that the decoding at least starts always at a valid state.

-Panu

[Simon]

Thanks, Panu.

I've suggested that, but it's important to know it definitely.