What does STREAM_MODE mean?

SM_STREAM changes the way DREQ works. When SM_STREAM=0 (the normal mode), the sample rate of the song is fixed and VS1053 asks for new data when there is room in the stream buffer.

• This means: VS1053 will control the playback speed of the song.

When SM_STREAM=1 (the stream receiver mode), the VS1053 adapts to the speed of the incoming stream. VS1053 changes the sample rate a little bit higher if data is coming too fast and changes the sample rate a little bit lower if data is coming too slow. This is useful e.g. for receiving MP3 from satellite radio (the original purpose of MP3).

• This means: Microcontroller will control the playback speed of the song.

I'm having trouble playing an MP3 file using VS10XX and a microcontroller. What should I check?

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

-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. 

The initial problems in starting to hear MP3 music from VS1011 are usually the same. The usual remedies include:

- Select NEW_MODE if it's possible. Don't set "SHARED MODE" if you can connect both XCS and XDCS to your microcontoller.

- 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).

- 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.

- 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 (1/6 for reading) of the chip clock.

- Note that before setting the CLOCKF register clock doubler/multiplier the SPI bus speed must be less than 1/6 of your crystal clock.

Why so many pull-down resistors for VS1000 data lines?

The ROM firmware of VS1000 assumes a Nand Flash and 5 buttons connected to the Nand Flash data bus with pull-down and pull-up resistors. The firmware reads the buttons every now and then. If the data line is pulled low by the resistor then no action is taken. However, if the line does not have a pull-down resistor it might be high after the last Nand Flash transaction. This causes an "false" button event to be recognized by the firmware. This can cause unpredicted results. 

Either use pull-down resistors on Nand Flash data signals D0 .. D4 or write a custom software with a custom keyhandler that ignores possible false key events.

How can I make an Internet Radio based on VS1053

It's a relatively straightforward task to make an internet radio from VS1053. You need to have a microcontroller running some TCP/IP code so you can open a TCP connection and then just feed the bytes from the TCP connection to VS10xx. Additionally, you'll need some buffer memory for the incoming packets - at least a few kilobytes but more buffer memory will give you better resilience with bad network connections.

For reference on the hardware/software design, you can look at some existing solutions.  There are at least 2 published internet radio designs that use VS1053 (or its predecessor): the Microchip Internet Radio and the Elektor Internet Radio.  It's easy to find info on them in the net. If you have trouble finding the schematics, contact VLSI support.  The Microchip internet radio obviously uses a PIC and the Elektor Internet Radio uses an Atmel ARM as the host processor.  In addition, several commercial manufacturers use VS1053 because it's so easy to use and versatile,  but we can't give any information on those.

For information on how to write software that communicates with VS1053, I suggest that you first of all read the datasheets and application notes and then look at our example microcontroller software at http://www.vlsi.fi/en/support/software/microcontrollersoftware.html

Start your software development as you would make a "normal" MP3 player. Connect VS1053's Serial Control Interface (SCI) and Serial Data Interface (SDI) to your microcontroller's SPI or SSI port. Preferably use separate chip select lines for both (xCS and xDCS). Connect DREQ to an IO pin to the microcontroller, preferably an interruptible one. Execute VS1053 reset as in the microcontroller source example, and do the Sine Test to verify that you can get a beep. Then send an MP3 file to the SDI port and enjoy the excellent sound quality.

At this point, you should verity the functionality of your microcontroller's TCP/IP code by doing some basic networking stuff. For example you can install Apache to your PC and connect to it using your microcontroller to see that you can access a web page.

Then pick an internet radio station with MP3 data format. Listen to it using your PC and use Ethereal/Wireshark to see how the connection is opened. Make note of the IP address, port number and the HTTP GET line used to request the connection. Then do the same with your microcontroller. Once you open the TCP connection and send the correct HTTP GET line to the connection, the radio station should start sending you the data. Feed the response bytes to VS1053 and listen to the broadcast.

Finally, after you get it working, you might want to adjust the sample rate of VS10xx manually because you have information on the fill level of your big buffer, which the VS10xx doesn't have. This way you can adapt precisely to the incoming bitstream speed and eliminate all problems that you might have from buffer overruns/underruns. 

An MP3 radio station starts playing almost instantaneously. With WMA/AAC bitstreams, there are some ways to make it start faster. Contact support for details.

Why is the CVCC capacitor smaller than the one for AVDD or DVDD?

Like all regulators also the VS1000 requlator requires filter capacitors. It is recommended to use one 10uF cap for the AVDD and one for the DVDD regulator output. Also 100nF capacitors should be connected from all other AVDD and DVDD pinst to ground.

The CVDD capacitor should be 1uF. Also a one mega ohm (1MOhm) resistor should be connected in paraller with this cap. This drains the capacitor faster during power down an prevents the regulator from starting up when the power button is released after power down.

Standalone application - VS1011 vs. VS1003

I have a technical query regarding VS1003, comparing it to our current project with VS1011. VS1011 reference design (i.e. standalone player) has 3 user controls (play/pause, volume-/prev, vol+/next). We cannot have more user controls because there is not enough internal memory for extra firmware.

VS1003 http://www.vlsi.fi/fileadmin/app_notes/vlsi/vs1003_plugins.pdf tells me that I can have 16 or 32 buttons, yet it has exactly the same internal memory (5.5KiB) as VS1011.

Can you find out how the extra user button firmware is fitted into the VS1003?, or am I misunderstanding something?

VS1003 16/32 button application uses ADC of VS1003. Buttons make resistive string.
Measured voltage level indicates the key pressed. This application can not detect two buttons
pressed at the same time since resistive sting makes priority chain. The difference of VS1011 and VS1003 is that VS1011 does not have ADC while VS1003 does have.

VS1053b Ogg Vorbis Encoder: How large is the end-to-end audio delay in a streaming system?

The end-to-end delay depends on what you set as the maximum block size at the encoder end. See VS1053b Vorbis Encoder documentation, Chapter "VS1053b Ogg Vorbis Encoder Registers", SCI_AICTRL3 bits 7:4: Max samples in frame.

If you set this register to the minimum value 1, you will get a new frame after each 4096 samples. Because of byte alignment restrictions given in the document, you can expect to get a new frame after each 8192 samples. Then there are internal encoding buffers that are approximately 2000 samples, and the decoding delays from the receiving VS1053 which is in the order of 2000 samples, for a total of
approximately 12000 samples, or 277 ms at 44100 Hz. Add to that any delays caused by your transmission system (channel coding, transmission, receive, buffering, channel decoding and retransmission to the receiving VS1053) and there it is.

VS1053b Ogg Vorbis Encoder: How do I catch and send the Ogg Vorbis headers?

For an Ogg Vorbis decoder to work, it always needs to be able to read initial Ogg Vorbis headers. The headers contain dynamic compression tables, channel mappings and other important stuff. Typical Ogg Vorbis encoders code these headers in approximately 4 KiB, but the VS1053 Ogg Vorbis Decoder uses slightly less than 1.5 KiB to encode them.

There are cases where the transmitter of an Ogg Vorbis stream is on all the time, but the decoder or several decoders are connected to the stream only afterwards in such a way that it is not realistic to start the encoder all over again (e.g. you don't want to restart the encoder each time a new listener is attached to an Internet radio). In such cases there must be an alternative way to determine and transmit the headers.

If the system is a closed system like RF headphones, the headers may be catched once and somehow sent to the receiver (or they can even be hardcoded to the receiver's microcontroller firmware and sent by it to the decoding VS1053 as the first thing). On open systems where there may be many listeners with different versions of the encoder / decoder, the standard headers may be transmitted during startup (e.g. internet) of the connection or trickled cyclically as a low-bandwidth sidestream signal along the main signal and collected by the microcontroller so that after a few seconds they can be transmitted to VS1053 so that it can then start playing audio data (e.g. digital radio).

The important headers can be detected as follows: When you start the VS1053b Ogg Vorbis Encoder, receive and store data until you run into the following bytes (XX means no matter): 0x4f 0x67 0x67 0x53 0x00 0x00 XX XX XX XX XX XX XX XX XX XX XX XX 03 00 00 00. This data is the first bytes that is NOT a part of the initial headers but of actual audio data.

After the VS1053 decoder has received the initial headers you may start sending audio data from any point of your stream.

VS1053b Ogg Vorbis Encoder: Can I stream Ogg Vorbis over RF?

Ogg Vorbis, just like MP3, WMA and AAC are compression schemes which take away as much redundancy of the audio files as possible. Because redundant information has been removed, there is no resiliance against bit errors left. The VS1053b Ogg Vorbis decoder can recover from errors as soon as there is new header data present, but still upto 490 ms of audio can be undecodeable after a bit error (when sampled at 44100 Hz and 128 kbit/s). Thus, if there is a significant bit error rate, e.g.  10^-5, the stream will be practically completely unlistenable.

For a good listening experience, there should be less than one bit error per 10 minutes in good listening conditions, which at a 128 kbit/s stream means a bit error rate 10^-8 or less. To achieve these kinds of error rates with a realistic RF channel requires effective channel coding. This is also true to Internet protocols like UDP where correctness of data cannot be guaranteed. (TCP does guarantee correctness, but it may require infinite resends, so you'll need a large buffer.)

All unreliable commercial media use channel coding, including but not limited to digital radio, mobile phones, CD's and DVD's. Depending on the application, channel coding typically increases the number of bits to be transferred by 20 - 200%.

Another important point is that the decoder needs to see the initial Ogg Vorbis header frames without any errors whatsoever. For details on how to do this, see the FAQ question: "VS1053b Ogg Vorbis Encoder: How do I catch and send the Ogg Vorbis headers?"

Is it possible to supply the VS1000 IOVDD externally?

Is it possible to supply the vs1000b IOVDD over pin 7 and 19, from externally with 3.3 volt and leave the IOVDD regulator output pin 30 open?

You can do this but I have three concerns:

1. please put >=10nF capacitor to the output pin (30) to prevent instability
2. please remember that IO pins have protective diode towards IOVDD.
   If IOVDD is low before IO pin becomes high the diode becomes forward biased.
   You need a series resistor per IO pin that has this kind of possibility in order to avoid
   overloading the driver circuit connected to the IO pin and/or prevent latch-up of VS1000. The right size of series resistor is 1-10kohm.
3. the input IOVDD pins must be connected together externally. It is good design practice
   to put small caps near each input IOVDD pin to filter current spikes.

How do I make a mono line-out connection?

You can make a mono line out connection simply by summing the left and right output together with two resistors. Connect a 1k ohm resistor in resies with with each analog output (LEFT & RIGHT). Then connect the resistorc to a DC-isolation capacitor. See "ESD protection" app. note figure 8 for more info.

Notice that this connection is not suited for use with headphones.

For a software that downmixes the decoded audio to mono in the VS10xx contact support@vlsi.fi

How can I connect external clock signal to VS10xx?

If your system has suitable pulse or sine clock available you do not need to use a separate crystal for VS10xx. You can connect external pulse clock to directly XTALI pin of VS10xx.

If the clock signal is sine you must connect it to XTAL through a small value capacitor. Also connect a 1Meg resistor between XTALi and XTALO.

How to determine the correct chip version from VS1011E registers?

Also: SCI_STATUS register says my VS1011E is actually VS1002. What is wrong?

VS1011E is an upgrade from VS1011B. The version number has also been upgraded. To determine the correct version from the registers read the SCI_STATUS register bits SS_VER and also SCI_MODE register SM_SDINEW bit.

In VS1011E SS_VER is 2 and SM_SDINEW is 0.
In VS1002 SS_VER is 2 ans SM_SDINEW is 1.

VS1011E starts in the VS1001 compatibility mode (SM_SDINEW = 0) and VS1002 starts in the NEW_MODE (VS1002 Native Mode) (SM_SDINEW = 1).

See datasheet chapter 7 and 8.6.2 for more info http:/www.vlsi.fi/fileadmin/datasheets/vlsi/vs1011.pdf

How can I make a Line Out connection?

I hear a loud pop when I connect the outputs to a stereo set. What can I do about it?

See latest info from application note: "ESD protection".

How should I connect the analog outputs?

See "ESD protection" application note.

Do you have software examples of using VS10xx?

For microcontroller example see http://www.vlsi.fi/player_vs1011_1002_1003/modularplayer/index.html and http://www.vlsi.fi/en/support/software/microcontrollersoftware.html

VS10xx code examples, patches and software tools: http://www.vlsi.fi/en/support/software.html


 

Where do I get example code for microcontrollers?

VS10xx KIT uses c51 microcontroller as master processor. The example code is available in

http://www.vlsi.fi/en/support/software/microcontrollersoftware.html

Power-on click problem

Can you please clarify how to use a transistor to eliminate the power-on click - this is the primary reason why we re-layouted out the board for the VS1011 versus the 1001, with the expectation that the newer chip (according to the documentation) eliminated this issue. We are planning on using the capacitor coupling.

VS1011 should not click when powered on.

To see how to do a power-down without clicks, see "Chapter 7.5.2: SCI_STATUS" in the datasheet. In short, you should read the register contents, then turn bit 3 (SS_APDOWN2) to 0, then wait for 10 milliseconds, then turn the power off. Pseudo-code for this would be:

   x = ReadVS1011Register(1);
   x &= ~(1<<3);                // ~(1<<3) = 0xFFF7
   WriteVS1011Register(1);
   Wait(10 ms);                 // If still clicks, try 100 ms
   Powerdown();

Can you please clarify the usage of the VCM (GBUF) pin

VCM (pin 42) is virtual analog ground output. Left and Right outputs have dc bias which is equal to voltage at VCM pin (about 1.25V). If you connect you earphones between Left/Right and VCM (instead of AGND) you can have dc coupling. But if you use AGND as ground reference you need to use ac coupling capacitors at the L/R outputs. So, basic idea of this pin is to save two capacitors and provide good bass. But never connect VCM to ground!

What is the price in 1K quantity?

Small quantities can be purchased from our Web Store see Buy.  Web Store has price reductions up to 500 or 1000 pcs depending on the product.

For bigger quantities please ask quotation from us.

Would you please tell me where I can get some samples?

Samples are available via our distributors.
Alternatively samples can be ordered from us by using our Web Store.

Adjusting the samplerate of the currently playing file

In vs1003B new value for the sample rate generation is only calculated when the samplerate changes, not when only CLOCKF changes.

To overcome this problem: read the samplerate, update clockf, then change the rate slightly to force update, then restore rate.

1) rate = read SCI_AUDATA & 0xfffeU
2) write SCI_CLOCKF
3) write SCI_AUDATA = rate + 2
4) write SCI_AUDATA = rate

Notes on the different communication modes in SCI/SDI

There are 4 different communication modes in various vs10xx chips:
 

• COMPATIBILITY_MODE - the VS1001k original communication mode
• NEW_MODE - standard SPI mode, default from VS1002 onwards. In NEW_MODE an SPI connected media can be on the same SPI bus with VS10xx but data must be first read to microcontroller and then sent to VS10xx.

• SHARED_MODE - SPI mode with single chip select pin - VS10xx must be the only chip on the SPI bus!

• PASSIVE_SPI_MODE - supported from VS1003 onwards; enables several chips on same SPI bus with "assisted DMA" transfers from media directly to VS1003 by connecting media data out to SDATA input pin of VS1003 and asserting xDCS when appropriate.  

Notes on parsing WMA streams

Here is a basic description of the operation of VS1003 and WMA:

VS1003 operation
- bootup, clear memory etc.
- DREQ -> '1' - search for decodable data from SDI

WMA found:
- Initialize bitstream by reading WMA header info and initializing the first packet
- Indicate WMA file by "WM" in SCI_HDAT1, zero SCI_DECODE_TIME
- Initialize WMA decoder
- Set hardware channels and frequency
- WMA decode loop until frame decoding failed or OUT_OF_WAV set in SCI_MODE

The WMA rewind patch replaces the main decode loop with a version that tries to resynchronize to the ASF packets.

Minimum requirements for WMA header

ASFFileProperties:

68 bytes skipped,
4 bytes = packetLength, must be > 0
rest skipped, if any

ASFStreamProperties:

16 bytes: ASFAudioMedia
24 bytes skipped
4 bytes: size of audio media (must be >= 24)
4 bytes skipped
2 bytes: stream number
4 bytes skipped
2 bytes: WMA codec (e.g. 0x61 0x01 for WMA 7)
2 bytes: channels
4 bytes: frequency
4 bytes: bytes per seconds
2 bytes: block align 4 bytes skipped
2 bytes: encode options rest skipped rest skipped

Migrating from earlier products

Here are combined some general migration notes regarding VS1003 and other VS10xx series devices. They are of help to you, who have used an earlier device and wish to upgrade.

Our chips are 98% compatible with each other. For the remaining 2%, read this text, datasheets, application notes. Throw the thing together and contact mp3@vlsi.fi for assistance with problems!

First of all, please check out our example schematics for VS10xx KIT (and VS10xx Proto Board where applicable):

http://www.vlsi.fi/en/support/evaluationboards/vs10xxkit.html

http://www.vlsi.fi/en/support/evaluation-boards/vs10xx-proto-board.html

Then about migrating; we have some migration guidelines under Application Notes that you should read.

Migrating to a new version of the VS10xx family (VS1001k -> VS1011B -> VS1011E -> VS1002 -> VS1003 -> VS1023) is quite easy since the devices are mostly compatible with their predecessors. Only where retaining compatibility would mean compromising chip performance, changes are made. These include dropping VS1001k BSYNC compatibility in VS1002 and changing CLOCKF register (clock multiplier added) in VS1003.

Note that any DSP code ("patch" or "user software") is chip version dependent and must be changed when upgrading.

At your earliest convenience, please migrate to NEW_MODE. See software examples:

http://www.vlsi.fi/player_vs1011_1002_1003/modularplayer/vs10xx_8h.html#a32

player_vs1011_1002_1003/modularplayer/vs10xx_8h.html#a32 http://www.vlsi.fi/player_vs1011_1002_1003/modularplayer/vs10xx_8h.html#a38

player_vs1011_1002_1003/modularplayer/vs10xx_8h.html#a38 http://www.vlsi.fi/player_vs1011_1002_1003/modularplayer/vs10xx_8c.html#a5

For VS1003 you might consider PASSIVE_SDI_MODE to share SPI bus with several devices.

VS1001k SOIC -> VS1001k LQFP

To migrate to VS1001-LQFP there is nothing special. Note that GBUF is not GND. GBUF is 1.3V buffer that can be used as headphones common and throw the series caps away. But please see ESD protection schemes in http://www.vlsi.fi/fileadmin/app_notes/vlsi/vs10XXan_output.pdf.

VS1001 -> VS1011

VS1011 is designed to be a drop-in replacement for VS1001, which it almost is. More clearly: if all datasheet directions for use of VS1001k are respected, VS1011 is directly compatible. For upgrading from VS1001k with minimum effort, please upgrade to VS1011E.

VS1011 and later chips require less (and less and less) voltage. VS1001k operating voltages are around 3.3V, VS1011 and VS1002 around 2.7V. VS1003 core voltage around 2.4V. All chips have separate analog/digital voltages, Analog voltage of 3.3V is OK for all chips, as well as digital 2.7V. But the ranges allow much leeway and lowering digital/core voltages lead to lower chip power consumption. On the other hand, keeping digital/core voltage high allows higher XTAL frequencies to be used (for adding DSP functions or sharing an existing crystal in system).

Please see the specifications from the datasheet of your target device. No VS10xx chip is 5V tolerant! Not even VS1001k!

VS1011B -> VS1011E

VS1011E adds new features, such as treble control and SPI boot for standalone players. Also the firmware is more optimized and plays all MP3 bitrates with minimum clock frequency (12MHz).


VS1011 -> VS1002

VS1002 adds the microphone interface and ADPCM encoding. The microphone interface is self-biasing so it can be left floating if it is not used.


VS1002 -> VS1003

VS1003 is a major new release. It adds WMA and MIDI support, the line input, and clock multiplier. The line input should be biased low (~ 10K resistor) when not used. VS1003 has separate power for the CPU core. Lowering the core voltage leads to low power consumption. The lower the clock frequency, the lower the CVDD can be.

The MAXIMUM voltage for the core VDD is 2.7V. If needed use series regulator to drop voltage for COREVDD. If price is an issue, you can also experiment with diodes to drop CVDD. Reset, however is detected from IOVDD; COREVDD should be always valid when IOVDD is valid.

The MAXIMUM voltage for VS1003 AVDD is 2.85 volts. Other VS10xx ICs don't have this restriction.

CLOCKF register value has changed in VS1003. It now controls the clock multiplier, allowable range and base crystal frequency.

VS1003 -> VS1033

VS1033 adds an AAC codec and a digital output (I2S). It has 4 more GPIO pins. They should be pulled low with a 100K resistor.

VS1033 -> VS1053

VS1053 adds stereo line-in and AAC+ and Ogg Vorbis codecs. The ADCs are high quality. You need to add 10nF capacitors near the pins as well as series resistos to cust the capacitive load for the other device that drives the inputs. Also please add RC filter to the output of the DACs when connecting them to external power amplifier. The DAC type has been changed for improved distortion but with a cost of some additional high frequency noise. This may cause noise in low quality power amplifiers.

Shared SPI and control registers

I thought XDCS was active low when writing data to the part and that XCS was active low when writing commands, but then 7.6.1 - 7.6.3 show using XCS being for SDI and SCI writes. Is this just because SM_SDINEW and SM_SDISHARED are both set?

Yes. Your application diagram suggests that you can use NEW_MODE and there is no need to use SHARED_MODE. NEW_MODE is recommended.

In new mode, XCS and XDCS are active-low SPI chip selects for both commands and data, just as you could expect.

In shared mode, the function of both is bundled into XCS to save one I/O pin in a microcontroller.

What if the part is used on a shared SPI bus - it will be in our application.

You can use the chip in a shared SPI bus when it is in NEW_MODE. The "straightforward" way of doing things is to read a block of data to a buffer in a microcontroller and then send it to the VS1002.

Can I connect VS10xx to the line input to my stereo system?

Can I connect the audio output of the vs1001 (pins left and right) to the line input to my stereo system? The line input has 47 k-ohm impedance. I know that a 100 µF cap and maybe a 15 ohm resister should be in series with each output line. Question, is 15 ohms enough or do you need some kind of buffer/driver on the output?

For proper line out connection see "ESD protection" application note.

How do I extract song and artist information?

VS1001 does not provide a means for extracting song and artist information from so-called ID3 tags from MP3 songs. It would be quite futile to even attempt adding such a feature to a decoder chip, since the traditional tags are at the end of a song, and would thus not be decoded before the whole song had been played!

However, extracting artist information is very easily done on the microcontroller side before starting playing a song.

This link points to a simple ID3v1 extraction C program. By compiling this you can extract ID3v1 tags and print them on screen.

ID3v2 tags are more complicated, but can be decoded on the microcontroller side quite similarily.

What changes have there been between VS10xxX and VS10xxY

For information of changes between device versions see the last pages of the appropriate datasheet.

I am using a clock that is not 24.576 MHz and the system plays music at the wrong speed. Why?

Check with the following symptoms and their solution:

Symptom: Always wrong playback speed, but not exactly 1/3 of correct speed

If you are always getting consistently wrong playback speed, check if you have successfully written a correct value to the CLOCKF register by first writing to the register and then reading your value.

Symptom: Always wrong playback speed at 1/3 of correct speed

If VS1001 is running at one third of its correct speed (which means that a 2-minute song lasts for 6 minutes), the reason is usually as follows.

VS1001 works with a fundamental frequency clock. Oscillators above 24 MHz are usually so-called 3rd harmonic clocks, which have a fundamental frequency of 1/3 of the actual clock speed. A 3rd harmonic clock has a base frequency of 1/3 of the nominal clock speed, and this would be the frequency that VS1001 would be working with, if working at all. Thus, if you run VS1001 with a 32 MHz clock, you usually end up running the chip at 32 MHz / 3 = 10.67 MHz.

To correct this you should use a fundamental frequency clock. As higher clocks of this kind are hard to get, it is generally a good idea to use a lower clock and doubling its frequency with VS1001's built-in clock doubler. I.e. instead of a 28 MHz clock (CLOCKF = 14000), use a 14 MHz clock and the clock doubler (CLOCKF = 0x8000 + 7000 = 39768).

Symptom: Sometimes wrong playback speed

If you are sometimes getting the wrong playback speed or the previous advice didn't help, the reason usually is the following: You have written CLOCKF properly, but there is a problem with the MP3 data you are feeding to VS1001. Because of that problem, the chip sees garbage instead of actual MP3 data, and finally resets itself. Unfortunately, the CLOCKF setting is lost when the chip self-resets. Thus, if garbage is sent, the playback speed may be wrong.

Anyway, you might not feed VS1001 with garbage, at least not on purpose. There may be two distinct reasons for the chip to think an MP3 file is bad. The first is that some programs create weird headers at the beginning of files that look like valid MP3 headers but are not (The worst file I saw actually contained a Photoshop image before the actual MP3 data and confused the decoder completely!). The other reason may be that you may have forgotten to send bytes containing zeros before or after a reset.

Another source of problem may be if you run VS1001 with a clock higher than 24.576 MHz and the chip just cannot cope with the speed / voltage combination. If you do this, see for overclocking issues below.

Whenever you run into this problem, you often also get the chip to occasionally freeze up so that even a software reset can't get it working again. If this is the case, you almost certainly have the problems described above.

I want to overclock my chip. Is it safe?

This depends on what you consider safe. Overclocking is usually safe in that sense that running a chip with a voltage that is inside Absolute Maximum Ratings doesn't break anything even if run at a very high clock speed. However, this is not guaranteed by VLSI Solution.

It is also worth noting that while some chips have been known to be overclocked for short periods even to 32 MHz with a digital voltage barely withing Absolute Maximum Ratings, VLSI Solution does qualify the chips only upto 24.576 MHz. While it can quite safely be assumed that a chip working at 2.7V / 24.576 MHz will also work with 2.9V / 26 MHz or even 3.3V / 28 MHz, this is by no means guaranteed by VLSI Solution.

Note, that it is possible to place large orders for chips qualified for other clock frequencies than 24.576 MHz.

So what exactly do I have to do to play a song?

• 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).

• 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.

DREQ sometimes freezes to always 1 or always 0. Why?

The reasons for this are the same as for other lockups, see "What is wrong when VS1001 occasionally locks up so that even software reset doesn't work?"

How do I find out if the chip locked up after a software reset?

Read back the contents of the MODE register after 250µs. If Bit 2 is still set, the chip didn't respond to the software reset. Try a hardware reset (remember that this will cause a slight clicking noise).

How to use the BSYNC signal?

I'm having some problems playing MP3 files. The Sine Test is OK, but when trying to play MP3 files, I get "weird" noises and sometimes the chip just plain refuses to do anything.

Please check, recheck and check again your BSYNC signal properties. It should be HIGH before the rising edge of first bit of an octet and LOW before rising edge of last bit of an octet.

If a byte oriented design is preferable, BSYNC can be used also as: BSYNC must be HIGH before rising edge of first bit of the first octet in a data chunk and BSYNC must be LOW before rising edge of last bit of the last octet in a data chunk.

This can be expressed further thus: it is allowed to do this sequence for a data chunk of n octets:

- BSYNC is LOW

- 1. bring BSYNC HIGH
- 2. send (n-1) octets
- 3. wait until you are sure the last bit has been clocked out
- 4. bring BSYNC LOW
- 5. send the last octet

- BSYNC remains LOW.

Usually problems such as the one you describe have something to do with BSYNC signal. Please check that first.

Oh, and keep a keen eye on the interrupt routines! Take a good look at the SDI sending routine to make sure you have no timing problems if an interrupt is taken in the middle or between any two lines of your code.

What does the op-amp at the output of the VS1001 Evaluation Board do?

What exactly does the op-amp at the output do ? Apparently it saves the large output caps. It is some kind of virtual ground or like the ground buffer in the BGA chip ?

Answer:

Actually, it is both. It is a ground buffer that generates a virtual ground, i.e. it does exactly the same thing as the built-in ground buffer in the BGA chip. It is recommended to use this kind of design when the system is used to drive earphones or other devices that don't have a fixed ground. If there is a fixed ground (like a connection to an amplifier), capacitors must be used instead.

Problems upgrading from VS1001 to VS1011

See application notes from: http://www.vlsi.fi/en/support/applicationnotes.html

Although we have tried to make migrating from VS1001k to VS1011 as easy as possible, some problems have occurred. If VS1001k datasheet rules are not violated and VS1001k recommendations have been followed, then migrating to VS1011 can be done with little or no changes to the circuit board.

Also, VS1011 boots up in VS1001k compatibility mode so the same MCU program is likely to work, except for software patches:

One of our customer used the new chip, VS1011, and tried to instead of the original VS1001 on their board. It seems no problem while the MP3 data stream transfer and they also got the information from DREQ. But they can not get any output from earphone out. This board works well when using VS1001.

User code (like the Loudness software for VS1001k) doesn't work in VS1011.

We have made available a VS1011 version of the Loudness v1.41 package. It is available for download at http://www.vlsi.fi/en/support/software/vs10xx-plugins.html.

The software is almost exactly the same as the previous one for VS1001k except for some minor internal modifications. The usage of the package is also just as with the old package. One thing to notice though is that register SPI_AICTRL[0] is register number 12 (0xc) in VS1011 and not 13 (0xd) as in VS1001k.

If interfacing rules of VS1001k datasheet are violated, problems can occur:

One of our customer used the new chip, VS1011, and tried it instead of the original VS1001 chip on their application board. It seems no problem with the MP3 data stream transfer and they also got the information from DREQ. But they can not get any output from the earphone. This board works well while using VS1001.

Customer is not using BSYNC (tied high). This means that in power-on startup wrong DCLK clock can cause out-of-bit-sync state and device may never recover. For some (unspecified) reason, VS1001 has worked fine in many applications without BSYNC. However, in VS1011 BSYNC must be used.

Thanks for the info, we got system working by sending a low pulse trig signal once into BSYNC during system initialization. Is that a correct design?

Yes, this works. However, if there are any bit errors in the transmission, the device will not recover before new hardware reset (XRESET pin) followed by BSYNC is given. You can have robustness by doing following:

When BSYNC is given regularly beginning of every 32 byte buffer frame, the device is likely to recover bit errors (caused by data or clock pin) such that it is not audible to user.

If BSYNC is given in the beginning of each song then the device will likely recover without hardware reset. BSYNC can also be given such that data is zero byte to simplify the clock generation by software (in the beginning of the song).


What about software reset? The software reset is just done in the beginning of power-up. Is that a correct design?

Software reset will not clear bit synchronization counter. So, it does not solve out-of-bit-sync issue. But it should be given in the beginning of the song because each MP3 file has its own parameters (such as bitrate) which are needed to extract correctly in the beginning of the song.

How high voltage does VS1001 tolerate for short durations?

I gave VS1001 a supply of 4.3 volts for a short duration of time on quite a few occasions (there was a problem with my hadwired board). The absolute positive AVDD and DVDD ratings for the chip are 3.6 volts, yet nothing whatsoever happened to it.

VS1001 may be able to last short voltage overloads upto 5 volts, depending on luck. Note, however, that it will not last for very long with voltages like this. In other words, if you try to use VS1001 with 5 volt components, its life time expectancy will shorten considerably. The word considarably here means anything from seconds to a few days or months of life time.

What is wrong when VS1001 occasionally locks up so that even software reset doesn't work?

If you get VS1001 in a mode where software reset bit SM_RESET simply doesn't work, you usually have managed to feed VS1001 a bitstream that is not a valid MP3 stream. This may also be caused because you may have forgotten to send bytes containing zeros before or after a reset.

It may also be that you are operating the chip with a voltage too low for the clock speed. See also overclocking.

How much buffering does VS1001 offer?

VS1001 implements two user-transparent buffers: an input bitstream buffer, and an audio output buffer.

The length of the input bitstream buffer is 16384 bits. In other words, at a constant 128 kbit/s bit-rate, the length of the buffer is 128 ms. DREQ turns off/on when there are more/less than 16128 bits data in the bitstream buffer.

The length of the decoded audio buffer is 512 stereo samples. In other words, at a sample rate of 44100 Hz the length of the buffer is 11.6 ms.