SparkFun Forums

[R'nway]

I recently purchased a VS1033 chip on a SparkFun breakout board. The chip is clocked at 12.288 MHz as recommended.
I've been able to communicate with the chip using both SDI and SPI, but I'm having a problem with the DREQ pin.

When I provide power, ground, and a reset high to the board, I see a 6.144MHz square wave on the DREQ pin.
At the moment, I've left all the other pins of the breakout board disconnected.
Sine tests still work just fine, and all of the other functions seem to be working.

Any idea why is this happening, and how I can fix it?

[markaren1]

7.3 Data Request Pin DREQ
...
Note: DREQ may turn low or high at any time, even during a byte transmission. Thus, DREQ should only be used to decide whether to send more bytes. It does not need to abort a transmission that has already started.

--------

I read it that the pin may oscillate when it is ready to accept data, but will only stay low when it can't accept any more data.

Given that, it sounds like the part is behaving as expected.

Not a totally splendid interface though...

Regards,

Mark

[ellierye]

I am seeing the same behavior. After contacting the chip manufacturer, they said that it can happen if the TEST input is not tied high (it is not attached to anything on the Sparkfun board). I tried a quick experiment with shorting the test pin to the pin next to it (31, a Core VCC pin) and then the oscillations stopped, leading me to believe that it is indeed the problem. I haven't tried permanently shorting them and dropping it into my mp3 player circuit (the chip was semi-working even without the DREQ line making any sense, but the music was choppy and corrupted as one might expect if it was being sent at the wrong rate).

Megan

[calmor]

After shorting the TEST pin to its adjacent pin (and trying to connect it to the output of the two regulators on the board as well), I'm able to play an MP3 of about 22050khz/96kbps. Anything higher sounds choppy and unbuffered. However, if I ignore the DREQ and just send as fast as possible, the song plays about 10x its regular speed (and garbled, of course).

I put the circuit on a scope last night and found that with the TEST pin shorted to its adjacent (and again the other regulators), I get a low frequency (21-26Hz), 25% duty cycle oscillation. The frequency seems to change with the bitrate, but not enough to matter. With TEST unshorted, I get the same 6.xx MHz oscillation.

Because the file goes through so fast when ignoring DREQ, I'm assuming throughput is not an issue. Increasing clock frequency of the SPI bus (on the SD card and the VS1033) have no effect, nor does increasing uC frequency - again all leading to throughput not being a problem. I am using separate SPI modules on my PIC. I can only assume at this point that the DREQ being low 75% of the time is causing the headaches. Pull-up resistors were not effective in stabilizing the pin.

Is anyone else seeing this behavior, or have any working examples of a VS1033 using the SPI bus and DREQ with higher bitrate files? Should I try compatibility mode instead of new mode?

[calmor]

Actually, I contacted VSLI and they informed me that I'd neglected to set the SCI_CLOCKF multiplier - will try that this evening but I will test that tonight. They also explained that the oscillation was normal operation considering a constant bit rate MP3, and considering the clock was too slow to process the other files, this would cause similar frequency oscillation (makes perfect sense).

Good customer service too!

[SFE-Nate]

I am seeing the same behavior. After contacting the chip manufacturer, they said that it can happen if the TEST input is not tied high (it is not attached to anything on the Sparkfun board). I tried a quick experiment with shorting the test pin to the pin next to it (31, a Core VCC pin) and then the oscillations stopped, leading me to believe that it is indeed the problem.

I just came across this post. I'll bring it to the engineer that did the design for the breakout. SFE tech support probably hadn't caught wind of this before because a) people figured out the work around for the DREQ oscillating b) weren't using the DREQ pin in their application.

Maybe we can get the PCB rev'd and have the TEST pin pulled high or at least a solder jumper so people can pull it high if they need it.

[mindthomas]

However, if I ignore the DREQ and just send as fast as possible, the song plays about 10x its regular speed (and garbled, of course).

This happends because the SM_STREAM parameter is set in the SCI_MODE register.
As the datasheet says: "SM STREAM activates VS1033’s stream mode. In this mode, data should be sent with as even intervals as possible and preferable in blocks of less than 512 bytes, and VS1033 makes every attempt to keep its input buffer half full by changing its playback speed upto 5%."

[SFE-Nate]

Looks like there is a rev in the works, no idea on the ETA though.

[seniorquico]

In my case, absolutely nothing worked. After shorting CVDD3 (pin 31) with XTEST (pin 32) everything worked perfectly. The datasheet recommends pulling XTEST to IOVDD, but CVDD worked fine.

I had tossed the breakout board aside for the past couple months thinking it was fried. Thanks so much for working with VLSI and posting here! Looking forward to the next revision!