VS1053b - sine test starts after 2min40sec

[prot]

hi all,
I have this problem with my VS1053b board, SPI communication seems to work, I can read and write to sci_mode, sci_status registers. I can set the clockf register, sw Reset works too. On the same board I have a micro sd card (same SPI bus) with it''s own CS pin. The VS has SDINEW=1, SDISHARED=0.
I can access the sd card, perform "dir" and other operations.
Now the problem: I cannot play any mp3 file. I have 1.23V on LEFT, RIGHT and GBUF. There's a popping sound after init. GPIO0 and GPIO1 are pulled down through a 100k (I checked and I measure 0.012V on both).
Yesterday I thought the sine test is also not working but after reflashing the sw once (atmega328p) I was looking on the data sheet for about 3 minutes and still had my headphones on and the sine test started. So, to be more precise, the sine test starts 2min and 40sec after rebooting.
I tried different clockf configurations, and the delay gets smaller (down to 1min30seconds) or stays the same.

Any ideas how to solve this ?

Thanks in advance

[pasi]

Having a microsd card on the same SPI bus is not recommended, especially if the user can eject/insert the card at any time. The reason is that you should not access the vs10xx before the uSD card communication is initialized, or the uSD card can mess up the communication and/or enter the SD communication mode (because SD's chip select is high) -- and you can only escape that mode by a SD power cycle. In other words, the uSD has to have had SPI mode GO_IDLE_STATE initialized before vs10xx is accessed.

Can you read and write SCI registers without the uSD card connected?

Are you using the old sinetest (needs SCIMB_ALLOWTESTS set in SCI_MODE and starts through a pattern sent to SDI), or the new sinetest (started by writing SCI_AICTRLx parameters and SCI_ADDR)?

It looks like the vs1053b is out of reset and clock is running, because the analog outputs get biased to 1.23 V. Mono mp3 should play correctly with 1.0x clock, i.e. without any SCI writes.

[prot]

thank you for your reply.
I will test the SPI communication without an inserted sd card and post the results later.
*a bit off topic: I used the vs1011 and I believe the vs 1003 with the sd on the same bus before and it worked ok.

back on topic:
Basically I have 3 slaves on the SPI bus, the SDCard, the VS SCI and VS SDI, each with its own CS pin. First I initialize the SD Card, make sure everything works, then do a HW reset, wait 500ms, then a SW reset of the VS1053b.

I am using the new sine test (writing 0x4022 to the AIADDR register). Is there a video or sound sample of how this test should sound like ? I think mine is not only delayed but it's also very slow rising.
What could be the cause for that 3 minutes delay between sending the sinetest command and the actual test start ? Something's keeping the VS on hold or extremely slow

LATER EDIT:

I checked and I get the same results after removing the micro sdcard

[pasi]

You have activated the Sine sweep test (0x4022), which produces a sine of slowly rising frequency. Everything is probably correct, and you are just not hearing the low-frequency start of it -- the low frequencies not reproduced by your headphones/speaker.

However, a different CLOCKF value should not affect how quickly you start hearing the output, unless you also change the samplerate from the default 8kHz. You can set the samplerate by writing to SCI_AUDATA (before or during the sweep and sine tests). A higher samplerate produces a faster sweep.

AIADDR=0x4020 starts the sine test, where you can se the frequencies by writing values to AICTRL0 and AICTRL1.

[prot]

thanks again.
I managed to run the old sine test, which plays as expected. I still can't get an mp3 audio file to play. I can fetch from the sd card and sent the data bytes to the SDI but there's no output. I have 1.23V on Gbuf/ Left/ Right and Rcap pins. All the GPIOs are pulled down. I think it's a sw issue.

The microcontroller I'm using for this is an AVR (M328p) and it runs at 8MHz. I have a 64 scaler in the SPI config so I start with CLOCKF 00000000_00000000 and SPI running at 125kHz. After initializing the sdcard, I reset and initialize the VS1053b (set the MODE and VOL registers).
Then right before starting to play a file I set the clockf register. I used different values here, including 0x9000, 0x8800 and 0x6000.
After setting this register I also speedup the SPI (up to 2MHz) and then I start fetching the audio bytes and sending them to SDI.

Am I missing something ?

[prot]

so now I got the MP3 file to play but it's very slow and choppy. Changing the CLOCKF register doesn't bring much. I tried pretty much all multipliers and ADD values, with different SPI speeds but the only thing achieved was to make the sound even slower and choppier than before.
I also tried Panu's recommended values for a 1053 CLOCKF register: 0x9000 and 0x8800.. but there's no improvement of the output sound.
The files I tried to play are mp3 with max 192kbps bitrate.

[Hannu]

Hi,

Some random ideas to try.

Have you really measured the frequencies? ATMega328 has divide by 8 clock fuse. That thing has surprised me some times.

Can the MCU read the SD card fast enough. If you just read and discard the data, are you able to read the file faster than real-time?

Another idea which comes to my mind is if you are respecting DREQ.

You could send DREQ to LED. If it is lighted much you aren't sending fast enough. And if you implement some debug code which checks just before starting the SDI transmission DREQ that it is indeed high.

[prot]

thank you so much for taking time to reply. here's what I checked:
Atmega's fuses are ok. Divide Clock is disabled. The clock is indeed 8000000 Hz. All VS1053b 's GPIO pins are pulled down (100k) to GND.
I checked Rx and Tx and made sure Rx is pulled high (100k) to 3.3V and Tx floats.
I 'm pretty sure that at 2MHz I am able to read from the SD card fast enough. But I'm not 100 % sure and I do see how this could cause my problem. How can I check this ?

Yesterday I started to read and print the SCI registers for debugging purposes. Everything seems ok except for the Status register. It reads 48 and I think it should be 40. I'll take a look at the SCI_AUDATA register as soon as I can. Could the MIDI mode still somehow be activated ?
&H48 means the SS_APDOWN2 is set. I also tried manually resetting that bit, although the manual says this should be handled by the system fw only. The audio play sounds the same.

I'll check DREQ right before starting to send data. I do have some LEDs on the microcontroller's board and I can use one of them to match the DREQ state. Thanks for your advice.

And if you have more ideas I'd be happy to hear from all of you. I'm starting to run out of places where to look for an error.

[prot]

Can the MCU read the SD card fast enough.

I think you were right. I soldered a wire between DREQ and the anode of a LED. During play the LED is ALWAYS on. So your assumption must be correct, the DREQ is always high, the data is not being sent fast enough.

I then started lower the bitrate of the mp3 files. Ignoring the poor sound quality which was expected, the LED starts blinking (below 96kbps). I also tried to send 64 bytes instead of 32.. and it gets even a little better. It's still a long way from what it should be.

I used the VS1011 in some of my projects, and I'll try to dig out the software I wrote for it. Can't remember if I used it in not shared mode though.

[prot]

I think it's working now. I found a couple of different problems.
The routine for sending audio data to the SDI was faulty and pretty slow, I wrote everything from the scratch again.
There was a cold solder joint on the sd card's CS pin. I'm sure you know how frustrating can be when something works sometimes and then stops working without reason, and a few minutes later, it works again.

I also changed my microcontroller's crystal from 8000000 to 11059200 Hz. Now the SPI runs at about 5.5 MHz.

I can now play 320kbps MP3 at normal speed and without glitches.