Strange behaviour with Due

[Anonymous]

I presume that I am doing something silly, but I can’t find what it is.

I’m using a Sparkfun MP3 shield with an Arduino Due and the special Due branch of your great software. I have also re-routed pins 11 to 13 of the MP3 shield to the Due’s special SPI connector.

In SFEMP3ShieldConfig.h I have:

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

I have the patch files in the right folder of my SD card.

At the moment, I am trying a  simple test that just:

1- sets up the SD card and reads a text file. (all works fine); then

2- calls MP3player.begin(); (this returns with no errors); then

3- calls MP3player.playMP3( “music.mp3” ).

Given that steps 1 and 2 seem okay, I presume that my hardware is correct and only have a software issue.

My test program never returns from the third step. Tracing what I could, I note the following behaviour:

– SFEMP3Shield::playMP3() calls Mp3WriteRegister(SCI_DECODE_TIME, 0) wherein there is a line that says if(playing_state == playback) then call refill().

refill() is then called multiple times for around 40 seconds at which point it reaches the end of the file. This is strange. The MP3 file is 8,908,772 bytes which, according to the file properties in Windows, should play for 5 minutes and 19 seconds. Furthermore, the file is recorded at 223 kbps (27.875 kBytes/s) but the software thinks it is at 16 Bytes/ms. (Perhaps this discrepancy is due to the fact that the file is recorded at variable bitrate?)

It looks like the software hangs when the program returns from the above mentioned Mp3WriteRegister() call and then re-enters refill().

I don’t understand why refill() gets called from within  Mp3WriteRegister(SCI_DECODE_TIME, 0). There is a line, playing_state = playback just before it. Presumably that should instead be after it, but there must be another problem somewhere else too as it shouldn’t reach the end of file after just 40 seconds and there ought to be music being played. I hear nothing.

I have checked SFEMP3Shield::enableRefill() and none of the timers or interrupts are being enabled.

I’d be grateful for any guidance you could provide.

[Anonymous]

The problem seems to be that the line while(digitalRead(MP3_DREQ)) in SFEMP3Shield::refill() is always true for some reason. Any idea how that could be?

I’ve checked the value of digitalRead(MP3_DREQ) in various places leading up to initialisation. It is zero up until vs_init() is called in SFEMP3Shield::begin() which implies there is not a hardware problem – at least not with that I/O port. SPI would also seem to be fine judging from my ability to read data from the SD card.

Could I have a chip select issue?

BTW, I also tried the FilePlayer example. Initialisation is fine and it lists the MP3 files correctly but then I see the same problems when trying to play a file.

I also get the same problems if I do not define USE_MP3_REFILL_MEANS.

 

[Author]

Posts