[Michael P. Flaga]

First thing that comes to mind:

Comment out <a href=https://github.com/mpflaga/Sparkfun-MP3-Player-Shield-Arduino-Library/blob/master/SFEMP3Shield/SFEMP3Shield.cpp#L827>SFEMP3Shield.cpp Line 827</a>

You can see that if the file type is detected as MP3 that getBitRateFromMP3File(fileName); attempts to scan the file for the header to predetermine the bitrate. This is optional and may remove your noticeable delay for larger files.

[Michael P. Flaga]

Try changing the following in SFEMP3ShieldConfig.h from

#define USE_MP3_REFILL_MEANS USE_MP3_INTx

to

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

This will make the demo run without using the interrupts. The SFEMP3Shield library does not directly affect the millis() or its sourced components. I suspect the above change will confirm that it is an interference of interrupts. Between the Arduino’s core library for millis() sourced by Timer0’s Overflow interrupt vector and the VS1053 DREQ. Where the MP3 driver reads ahead the MP3 file, while in the interrupt, and the TIMER0_OVF_vect’s increamenting of the timer0_millis value.

I have toyed with reducing this overhead or blocking of other interrupts. But it is a major change and lot of work.

I think changing to USE_MP3_Polled is a quick fix. Note that you need the MP3player.available(); in the main loop.

 

[Michael P. Flaga]

Several things.

1) IDE 1.5.2 requires SdFatBeta20130207.zip to solve your main problem. Where the current SdFatLib sdfatlib20121219.zip contained in the current release of SFEMP3Shield has the above known, fixed in the beta.

2) You say you installed the latest compiler. Do you mean IDE or avr-gcc. If avr-gcc then, please see my SdFat Issue #9 as it discusses actually confirming that SdFat works with 1.5.2, both with Arduino’s default avr-gcc 4.3.2 and the latest avr-gcc 4.7.x Where the later requires a fix to SdFat, that is pending the next release of SdFat. Alternatively/simpler you can comment out the offending line, for this issue, as it is cosmetic, if you are using avr-gcc 4.7.x. To avoid the problem with latest gcc.

//Serial.print(FreeRam(), DEC);

Either way Issue #9 documents that SFEMP3shield can work with 1.5.2, if SdFat is fixed.

I had been hesitant to update the SFEMP3Shield library with the beta, being a beta. Where as it appears to work fine for me.

[Michael P. Flaga]

Nice Job.

As you have one speaker, you may want to include MP3player.setMonoMode(1); near the MP3player.setDiffertialOutput(1); as not to have there virtual sound effect.(what ever that is).

You may want to look at http://mpflaga.github.com/Sparkfun-MP3-Player-Shield-Arduino-Library/_file_player_8ino.html which you could easily adapt to auto detect and cycle through any file name, with the button.

[Michael P. Flaga]

Please look at the Git Hub Project Page’s Trouble Shooting Guide

It explains the problem you are seeing.

Note the following in the examples, as to instanciate the sd prior to its use.

SdFat sd; // newly required in 1.01.00 and higher

[Michael P. Flaga]

Strange. Please, note in the current example MP3Shield_Library_Demo.ino :

…
} else if(key_command == ‘O’) {
MP3player.end();
Serial.println(F(“VS10xx placed into low power reset mode.”));
…

Compiles just fine. Since your reported error did not error on the isPlaying, It sounds like the library you have linked to is prior to 1.01.00, when SFEMP3Shield::end() was added.

The SFEMP3Shield::end() function was created just for this; to save power. There is a low power soft mode, but the data sheet states the most power savings is done by putting the chip into reset. Which is what end() does. And you can come out of reset by re-initializing the VS1053 by calling SFEMP3Shield::vs_init(). No need to re-call SFEMP3Shield::begin() which only deals with the Arduino’s pins.

Hence the MP3Shield_Library_Demo.ino example has

…
} else if(key_command == ‘R’) {
    MP3player.stopTrack();
    MP3player.vs_init();
    Serial.println(F(“Reseting VS10xx chip”));
…

 

[Michael P. Flaga]

I have updated the above mentioned quick example. As it was typical of prior to 1.2.0

The __brkval and __malloc_heap_start errors are from the avr-gcc 4.7 as I had found that SdFat Lib has issues (and found a fix by tweaking SdFat).

I was not pointing out that a windows solution would help. Where as I found on that web page Andy Brown documents and provides updated Arduino Core Library fixes (near the bottome) that are needed to make avr-gcc 4.7 work.

I note that stock Arduino IDE comes with avr-gcc 4.3 for both 1.0.1 and 1.0.3 (infact all of them) and not 4.7. So installing 1.0.3 simply put the 4.3 back into play. I am not sure how the Linux distro of Arduino places and uses the avr-gcc. So I can not make much comment there, except to say prior to re-installing Arduino IDE you were compiling with an un-supported avr-gcc.

I am glad it is working.

[Michael P. Flaga]

I have been poking around with avr-gcc 4.7.0 and find they enforce more and require fixes in the arduino libraries. as per http://andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/ . Initially I get an error similar to the above collect2 on sd. , but not the same.

I am not a Linux person, but I am suspicious that your avr-gcc that you are using is not the avr-gcc within/provided by the Arduino Library.  It took a lot of effort to discover the subtle tweaks required to get 4.7.0 working fully with this and SdFat’s Library. So you could go forward; by updating the libraries, as per the above link. Or go back to the normally used avr-gcc by Arduino (4.3.0).

Going Forward I found that SdFatUtil.h requires a minor update as to all the FreeRam to work. It is simplest to comment out the Serial.print(FreeRam(), DEC); in the setup(). Until I make an issue with SdFatLib.

[Michael P. Flaga]

I am not 100%, but I believe your problem is the version of avr-gcc. My google foo finds this issue with newer versions of avr-gcc, than I think what is found in the Arduino IDE.  I am running windows with 1.0.3 and likewise did not have problems with 1.0.1. or 1.0.2. Which uses avr-gcc 4.3.2 It looks like at least 4.7.0 and greater may have this issue.

Try replacing the line SFEMP3Shield.cpp:25 with

…
– PROGMEM uint16_t bitrate_table[15][6] = {
+ static const uint16_t bitrate_table[15][6] PROGMEM = {
…

Also does a “which avr-gcc” show you are using an instance outside that of the Arduino’s IDE?

what is the version of “avr-gcc -v”? (both, if other) to confirm this was the problem.

If the above fixes the issue I can check it in. As it appears to work fine on my version with the proposed change.

Reference: http://code.google.com/p/sdfatlib/issues/detail?id=39

[Michael P. Flaga]

The VS1053 has no non-volatile memory for you to alter. So it was nothing you did via software. The Error 4 and MemTest = 0x0 indicates a chip failure or at least a failure to communicate with the chip. I would also expect this to manifest in the Midi, but it may not be testing the CHIP’s ID. The Error code 4 is additionally in the library returning the begin() function before it can complete initializing the VS1053. Since it is not recognizing the CHIP. So other items may not work, properly. It appears it will basically will work with load volume.

I am not clear on the sequence of events. Is it playing but also issuing the errors? or was it that it was playing and now it is not, and issuing the errors, after the supposed MIDI experience?

Does the MIDI still work?

In the SFEMP3Shield::vs_init()  function un-comment the debug prints. (may need to fix them) and then what is the MP3mode register? It should be  0x4800. I suspect it is 0x0 like the Mem test. Which in turn would indicate you are not talking to the chip.

You can comment out the test checks of “if(MP3Mode != (SM_LINE1 | SM_SDINEW)) return 4;” and “if(MP3Clock != 0x6000) return 5;”  in the vs_init() and see what happens.

issuing the “i” command should result in the following:

Received command: i

HDAT1HDAT0VOLModeStatusClockFpversion[Bytes/S][KBits/S]PlaySpeedDECODE_TIMECurrentPos
0x00x00x28280x48000x400x60000x300000
Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V :

 

[Michael P. Flaga]

The most recent release of the MP3 library included and update of SdFatLib to sdfatlib20121219. Previous to this, it included sdfatlib20120719. http://code.google.com/p/sdfatlib/downloads/list . It is a long shot, but perhaps reverting back, may provide more stable operation.

Where as it sounds like some connector issue on the SdCard. perhaps cleaning it out with alcohol. or firmly pressing on it from boot through use to see if it is a cold solder joint. or even Re-flowing the board. Which may not be a possibility.

[Michael P. Flaga]

In the SdFat examples there are some test sketch’s. It may blank the SdCard.

I expect you have no other shields attached, as they may adverse affect.

It smells like the problem is between the DREQ pin of the MP3 chip and the D2 of the Arduino. POLLing lock up tells us that. And the Multimeter measurements of 0V, 3V and 1.8V lets us know it sounds like it is behaving as expected. But can not quite tell with out an oscilloscope, etc…

This is where I turn to having spares to swap out and make comparisons.

You may want to find some button examples and independently verify D2 is working on the Arduino. Then the attachInterrupt command and verify the INT1 is working on the chip.

[Michael P. Flaga]

Not enough to blame the shield. All you can say is the SdCard is not initializing.

I often get the same errors and strangely I find a solution is to swap cards between my laptop and exercise them and then swap them back. There must be some form of latch up, that is drained. Where I do think my MP3 shield is getting old and its connector is severely past its cycle life, several times a day for the past six months. May want to inspect the inside and ensure there is no debris.

I will put on my ToDo list an Example to test the MP3 aside from the SdCard. But won’t get to that shortly. but an alternative is to change the following lines to the below. Commenting out the ErrorHalt.

//Initialize the SdCard.

if(!sd.begin(SD_SEL, SPI_HALF_SPEED)); //sd.initErrorHalt();

if(!sd.chdir(“/”));// sd.errorHalt(“sd.chdir”);

Allowing the script to continue. There will be some warnings. but you should be able then run the “t” command to test the sinewave output. Indicating the MP3 chip itself is good.

Also you do not want any other cards or things using the SPI bus that are not disabled. Using an Ethernet Shield connected but not having its CS pin disabled will cause this symptom.

[Michael P. Flaga]

The 1.8V is likely the Multimeter’s representation of the signal bouncing between 0V and 3V very fast and the meter is showing the RMS(aka average) value of it. Placing Serial.println(F(“!”)); of very short/unique messages may help you identify what is actually happening. I often put the Serial.println(F(“.”)); in the libraries SFEMP3Shield::refill(). Noting that refill happens so much, that long messages can overflow and cause problems. Hence short messages, just enough to give you insight of where it is locking up.

Test by omission the INT1, what are the results after changing SFEMP3ShieldConfig.h

from

#define USE_MP3_REFILL_MEANS USE_MP3_INTx

to

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

Finally, there is a remote possibility that it may be the SdCard not working reliably, causing everything to back up.

[Michael P. Flaga]

The “Error code: 6” warning is just indicating that a particular file that is uploaded to the VS1053 as a patch is not found on the SdCard. Hence the print that it is a Warning. Should only be needed to fix some intermittent issues that are not repeatable, and some sound file types not used here.

The “+”, “-” and “i” causing a resume of play is a recently fixed issue in the recent releases, which caused refill() to occur after resumes. It is strange in that this symptom contradicts the observation that repeated track numbers don’t resume.

The symptom of playing just 1 second, at its most basic cause is that the initial refill() is executed but subsequent refill()’s are not autonomously issued. The investigation becomes; “Why does subsequent refill()’s do not occur?”

1. Is the DREQ not occurring properly?
3. Is the INT1 not occurring properly?

In the default SFEMP3ShieldConfig.h the library is configured for DREQ of the VS1053 to trigger INT1 pin of the ATmega328 to service an interrupt which then calls refill(). This appearently is not happening. The SFEMP3ShieldConfig.h initial value of USE_MP3_REFILL_MEANS can be changed from USE_MP3_INTx to USE_MP3_Polled as to exclude the Interrupt function.

Additionally there are the following self tests, which do not require streaming data from the SdCard.

[t] to toggle sine wave test

[m] perform memory test. reset is needed after to recover.

These diagnostics would help validate the VS1053 itself versus its interface and or the R3.

[Author]

Posts