Reply To: SFEMP3Shield works with Arduino Due

[Anonymous]

I think that there is a misunderstanding. I am not using an IR receiver. I only have the Due and the Sparkfun MP3 shield.

1- I saw the use of USE_ARDUINO_SPI_LIBRARY in Sd2Card.cpp but since we use a different chip select pin for the SD card and for the MP3 chip I couldn’t see why there should be a conflict.

Any way, evidently there is a conflict so either I change SFEMP3Shield.cpp to use the native DMA capability of the Due or I set USE_ARDUINO_SPI_LIBRARY to 1. I’ll keep life simple and stick to setting USE_ARDUINO_SPI_LIBRARY to 1.

2- I understand the extended SPI functionality and the use of SPI_CONTINUE and SPI_LAST. I was just surprised that only using SPI_LAST should cause problems. I suppose it’s because there needs to be some kind of delay between each write if SPI_LAST is used.

More importantly, I was surprised that the source code that I downloaded from you used SPI_LAST for every write which doesn’t work for me. Either the source code on GitHub is not the same version as you’re using or I have a hardware issue.

I suppose that it’s possible that yours worked purely by luck and that the clock frequencies of my system are very slightly different – just enough to cause problems.

3- “I assume you want to say SFEMP3Shield::playMP3() instead of SFEMP3Shield::begin()”

Yes. Apologies, my mistake.

Yes, I do call SFEMP3Shield::available() in my loop() function.

I have tried MP3Shield_Library_Demo.ino and I have the same problems – whether I have #define USE_MP3_REFILL_MEANS USE_MP3_Polled or #define USE_MP3_REFILL_MEANS USE_MP3_INTx.

I have tried two different MP3 files: one I created myself and one I downloaded from Amazon. The Amazon properties are:

sample rate of 44.1kHz, 16 bit, 250kbps, contains album art and ID Tags ID3v2.3 and v1.1

My file is:

sample rate of 44.1kHz, 16 bit, 223kbps, contains ID Tags ID3v2.3 and v1.1

“That means your file plays entirely with that modification?”

No. Unfortunately neither of the two MP3 files I have tried work.

What I see is that SFEMP3Shield::refill() gets called several times but the total number of bytes written to the MP3 chip is less than 2kB. The exact amount varies each time I reset the chip but is never more than 2048 bytes.

Since there is a variation, it feels to me like there is some kind of clocking problem. Maybe something is too fast or there needs to be a pause between a read or write maybe.

4- I have tried changing setup() so as to no longer try and play an MP3 file but instead run the memory test, SFEMP3Shield::memoryTest(). I get a result of 0. The correct answer should be 0x83ff (see p67 of the data sheet http://www.vlsi.fi/fileadmin/datasheets/vlsi/vs1053.pdf).

BTW, the definition of SFEMP3Shield::memoryTest() is wrong. It is defined as returning an unsigned value. This should be changed to signed since the function can return -1. Same for SFEMP3Shield::disableTestSineWave() and SFEMP3Shield::enableTestSineWave().

I wonder if I have a hardware problem. However:

– I can read the contents of a text file on my SD card with no problems;
– the diagnostic print outs from SFEMP3Shield::vs_init() , SCI_Mode and SCI_Status are correct.

5- The diagnostic print out for SCI_ClockF in SFEMP3Shield::vs_init() I get is 0. Is that the correct value?