Problems with Sparkfun MP3 straight from the box

[Anonymous]

Hello. 🙂

I come to you today because you seem to be some of the foremost experts on the MP3 shield from Sparkfun. I have a problem that I have been struggling with for a few days, and would like to ask your opinion. I recently bought an Arduino UNO R3 and the MP3 shield from Sparkfun. Initially I used it to play real-time MIDI, and at this it did wonderfully. I then went over to try to play MP3 files, and things got a lot more difficult.

I started off trying to use the code on the Sparkfun quick-start page, with the recommended code, files and bit rates. No sound were produced. I tried fixing it, and eventually managed to write my own code that plays music, but there is a lot of noise, popping, and sometimes maybe even sped up tracks. I then found your code, downloaded and tried to run the demo program. The program compiles and uploads fine, and displays the menu in the serial monitor window. I tried a few commands like ‘d’ and +/-, and everything seems to be working fine. The SD card shows up with the files and everything. I then try to play track001, and this is when things start to be difficult.

I get one second or so of music, before it stops. And before you jump to conclusions, I know this is a common problem mentioned on the forums. 😉 The track does however not continue 1 second when issued the track number again, and throws an error code:1. It does however proceed a second if I issue +/- commands or ‘i’, before the whole system freezes and I have to restart the serial monitor. If I start the track and then send a code like ‘iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii’ it plays the whole song and continues to function afterwards, although the quality is the same noisy popping I get with my own code.

On startup, I do get an error message saying:

“Error code: 6 when trying to start MP3 player

Warning: Patch file not found, skipping.”

Any help would be much appreciated, at I have been stuck for several days.

 

Have a nice day!

Espen.

[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.

[Anonymous]

Thank you very much for the quick reply Michael! 🙂

I have run some tests to clarify what is happening.

Sine-wave test:

Loud and clear and annoying if left on for too long.

Memory test:

“Memory test result: 83FF. Result should be 0x83FF.” As far as I understand, this is what we want.

USE_MP3_INTx/Polled:

Changed USE_MP3_REFILL_MEANS from USE_MP3_INTx to USE_MP3_Polled and back. Tried showing SD-card directory and play track with both. With INTx, same behavior as reported before, with Polled, SD-card directory does not show, and no track can be played.

DREQ logic levels:

I did some tests on the DREQ pin using my multimeter, and observed some strange behavior. Note that it is a low-end multimeter, so this is not tick by tick readings, more like second by second.

Startup: 3.3 V.
Running tests (d, m, t): 3.3 V
Start playing track: Drops quickly to about 1.4 V before stopping music and settling steady at 1.84 V. This part seems strange to me, as I was expecting 0 V or 3.3 V. It stays at 1.84 V until I issue another command.
From there, sending ‘i’: Drops to 0 V before going back to 3.3 V, stopping the music and refusing any more commands until I reset the system.
From there, sending ‘iiiii…’: Drops to 0 V and stays there spiking a bit every now and then until track is finished, then returns to menu and functions like normal. (I.e. after a reset)
This does however just happen with one of the tracks. (The one with bells from Sparkfun). The short track (drums) only plays the one second, then freezes the system no matter what I do. I suspect this being related to the fact that it is so short.

I don’t really know how to test whether the INT1 is occurring properly, but if you would advise me how I can test that too.

In my opinion, something seems to be rather wrong with the DREQ. Do you think this is a reasonable assumption? I am also wondering if this means that the board if broken, or just something else causing it?

Thank you again for all your help, it is most appreciated!

Have a nice day! 😀

[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.

[Anonymous]

I did some more testing today, while printing the !. If I set #define USE_MP3_REFILL_MEANS USE_MP3_Polled, the SD card does not show up and no song is played. If i issue ‘d’ command, it prints:

“Files found (name date time size)”

but does not show any files available. I also loops through the refill() from the moment I reset the chip. The DREQ value is a steady 3.3 V.

If I put it back to USE_MP3_INTx, I get some varying results. If I try to play a track, I get 1 second of music again, and the serial monitor prints around 16-25  refill loops issued. In these loops it also prints:

Playing:

!

(Random assortment of symbols and squares)

by:  (Some squares, 1’s and U’s)

Album: (More random symbols and squares)

Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V :

!

!

etc.

The behavior has changed a bit since yesterday in that I can no longer issue any commands at this point. It is now frozen, and I have to restart it. If instead of ‘1’ I issue ‘1iiiiiiiiiiii’, I still get more of the music, but it also freezes in the end of this sequence, and never gets back to the menu. The system seems to freeze close to the end of the song. The serial monitor prints that it has received the ‘i’ command a few times and prompts for new commands, until the end, where it prints “Received comma” “Received comm” etc. depending on what track I play. Then the system is frozen and I need to reset again.

The SD card seems to be working as far as I can tell on the computer, at least. Is there any way of testing this?

Thank you for all your help! 😀

[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.

[Anonymous]

Today I have some good news from my testing. I ran some of the example sketches from the sdfat library, and they seem to work as expected. I tried the Quickstart, timestamp, ReadWriteSDfat and bufstream. Everything seems to work, it read and write to and from the card, detects format and size etc. Still haven’t been able to get a new SD card for testing, though.

I do indeed not have anything else connected apart from the MP3 shield.

I did however run some tests on the D2 pin without the MP3 shield detached, and might have found some results at last. digitalRead() on D2 seems to be working as we would expect. I tested this with a simple button pushing sketch. I then moved on to attachInterrupt(), and here things are not working quite as expected. I tested using a simple button test, and note that my pressing of the buttons were slow and controlled. I did tests on all four trigger modes, and this is what I found:

CHANGE: When detecting change, it is always triggered on the rising edge, but some times it does not trigger on the falling edge.
RISING: Triggers on the rising edge as expected, and sometimes also on the falling edge as well. When not triggering on the falling edge, the LED flashes very shortly and dimly, as if the chip wanted to trigger, but remembered that it is not supposed to.
Falling: Does sometimes trigger on the rising edge as well as the falling one.
LOW: This was the hardest one to test, as it kept interrupting itself when the button was pressed.I added noInterrupts() and interrupts() inside the interrupt function along with a delay(500). Sometimes the system would trigger while low, and sometimes not. Not 100% sure about this test, but there it is anyway.

My question is then; do you think this is due to a defect board, or could it simply be triggered by bounciness in the buttons? And also, would this explain the behavior for just your code, or for all the codes? The code I wrote for example did not use any interrupts, although it did use the DREQ pin. All I did was to load the file into a buffer using a while loop and file.read(), and then transmitting it to the MP3 shield when DREQ requested more data. Using this method I manage to play entire files, although as mentioned the quality is not present. Could this be due to the factors we have observed so far?

I might just have to get some new parts like you suggested and try and compare.

Thanks for your time, I hope you have a nice day!

[Anonymous]

Hello.

I come to you today because I have fixed my last problem, and encountered a new one. I finally managed to get my hands on a different SD-card, and tested using that one. Lo and behold, I can play whole songs! 😀 However, something has happened to the shield, and it could easily be my fault. I now get an error code 4 every time I start the shield, regardless of what SD-card I use. The sinewave test does not give any sound, and the memory test returns 0 instead of 0x83FF that it should return. Error code 4 is non-default values in the SCI_MODE register, and if I have understood this correctly, this is something physically inside the VS1053 chip? I have played around with the MIDI function while being stuck on the MP3 side of things, and I am afraid I might have messed something up… Is there a way to reset the register to default values?

I hope to hear from you soon, as I can finally see a light in the end of the tunnel. 🙂

Thank you very much, and have a wonderful day!

[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 :

 

[Anonymous]

I am also having problems using the MP3 Shield right from the box. I’m finally getting audio but I’m having problems with it.

The project is this: I am using an Arduino and the SparkFun MP3 Shield connected to 9 buttons that will sit underneath and be triggered by the keys of the toy piano.

FYI, I downloaded the code from the SparkFun tutorial. I’m a novice and wrote no original code.
https://www.sparkfun.com/tutorials/295
I have been monitoring the audio via ear buds. I believe that my connections and my files on the SD card are all good. I receive no error messages when I verified the program on the Arduino software. Everything is grounded properly with 10k ohm resistors, I checked those readings on the voltage tester. But when I press the buttons I hear the audio in quick, choppy snippets.
Now my questions are: I have 6 analog inputs, are there other connection points that will allow for 3 more inputs/buttons?
I can get my audio to play poorly (quick, choppy snippets) once but I have to press the reset button on the mp3 shield in order to be able to trigger them again. Ideally the shield will be enclosed in the sealed piano so the reset button will not be accessible to the player. Is there any way I can trigger the files without having to reset the shield? Or do I connect a reset button to another connection point (Is this what MP3-RST stands for?)
On this page:
http://www.billporter.info/2012/01/28/sparkfun-mp3-shield-arduino-library/
I found this in the troubleshooting area.
Why do I only hear1 second of music, or less?
This symptom is typical of the interrupt not triggering the SFEMP3Shield::refill(). I bet repeatidly sendnig a track number will advance the play about one second at a time, then stop.
What board is it? Check Hardware Limitations. about Interrupts.
Are you trying the SFE provided test files ? Or some homemade mp3 files? The SFE test files are nice as they are Immediately LOUD.
Interrupt problems may cause mp3 files that have a quiet lead in (or ramp up of volume) to be falsely diagnosed as not playing at all. Where the first 1 second may not be loud enough to be heard.

I’m trying to check this out but I’m having a hard time understanding how to use the SFEMP3Shield.
I’m going to read it and re-read it until it makes sense to me.
Thoughts?
Thanks again for any insight you can provide.

Images can be found here:

http://www.flickr.com/photos/liz_noise/tags/toypiano/

[Anonymous]

Hello Liz_noise, and welcome to the forum.

I received some great help here, and would very much like to help you out both with your problems and in understanding the MP£ shield in general.

First of all, I would recommend you to get the MP3 library that Bill and Michael was written. http://www.billporter.info/2012/01/28/sparkfun-mp3-shield-arduino-library/

I have used this library for a while, and it is fantastic, both for just plug-and-play style of using it, as well as using it to build something else. To install the library, see here: http://www.arduino.cc/en/Hacking/Libraries. And if you have any problems, let me know and I’ll try to help you out.

Now, you say that when you press “the button” out get fast choppy snippets. First of all, which button is it that you press? It’s been a while since I used the example sketch, but I thought that ran without input once it is started. Secondly, when you have gotten the fast snippets, do I understand you correctly in that you get about a second or so of music, and then the whole system freezes? Or does the song keep playing?

On the number of buttons, there are two other pins available that is not used for the shield, digital 5 and 10. If this is not enough I would recommend using an I/O expander such as this: https://www.sparkfun.com/products/8130

I am currently using 5 of these for a project I am working on, and they are working great. Another interesting product is https://www.sparkfun.com/products/9695, which gives you 12 touch sensors. I have a piano with 24 keys using two of these. For both of them, they are great because they only use two pins on the Arduino, no matter how many you have connected. (That is not quite accurate, as each one has a specific address, but more on that later. It you want to read about it, see I2C on Wikipedia, or feel free to ask for more details.)

As for the MP3-RST, it is connected to pin 8 and is used to reset just the MP3 board. This is done through the code, and can be useful if you want to switch from MP3 to real-time MIDI without turning everything off. (By the way, have you seen the MIDI mode? It is awesome!) The reset button on the shield is connected directly to the reset on the Arduino, which means it resets you whole system, and it starts as if you just connected the power.

As for the problem of needing a reset, I had a very similar problem. I did however use the library, so it might be different. I fought with the shield for weeks, and in the end it turned out to be the SD-card. I started off using a fairly cheap card, and got nowhere. This is because the read/write speed to and from the card was too slow, so the MP3 shield did not get enough data to keep going. Are you using a lower end SD card? If so, it might be worth your time to get a better one. I started off with a 1 GB card, but when upgraded to 4 GB from Kingston every problem I had vanished. Note that the size is not the same as speed, but bigger cards tend to have higher speed. Can’t help you out with exactly what you need, but if you give me some info on what you have, I’ll try to advice.

Just out of curiosity, what is it that you are trying to make? Judging from your pictures, it seems like you are wanting to build a piano? If so, why are you using the MP3 function? Mind you, you have a perfect piece of equipment to make a piano, but I am curious as to how you are trying to do it. I am finding myself quite interested in your project, so if you need any more help on the shield, code or otherwise, feel free to ask, and I’ll do my best to help you out.

Have a nice day!

[Anonymous]

Thanks for all the help, EspeMag!

Independently I was advised that I should be using the MP3 Trigger. The Trigger will do exactly what I need it to do with no code.

https://www.sparkfun.com/products/11029

It seems like it should solve my problem. It looks like it should solve all my issues regarding triggering issues and needing more inputs. I’m going to order this, install it, and report back.

I want to thank you for your help here. I will still have the MP3 Shield and will want to use it in another project once this one is completed so your links will come in handy.

[Anonymous]

Ah, that is great! It really seems like it would suit your situation perfectly. 😀

Good luck with your project, and if you need any help, you know where to go. 😉

[Anonymous]

Hi guys,

I have encountered a similar problem, and I’m not sure what to do! Basically, I am unable to get any sound of the board, whether it be from the sine wave test, or playing off the card. I am also getting the error code 6 and patch not found warning upon startup as well. Everything compiles and uploads without a hitch, and I can get to the menu fine, but when I enter the “1” command for the first audio file, it shows “Received command: 1” and then freezes without making any sound. When I run the “d” command I can see my audio files on the SD card fine, so I’m assuming that it is working properly. However, when I run the “m” command, I get result “0”, whereas it says I should get result 0x83FF.

Any ideas would be so much appreciated! 😀

Ezra

[Michael P. Flaga]

What happens when you issue the ‘t’ Generate Test Sine wave command?

You symptoms are strange. Please, Confirm you have not modified any of the code? (for these initial tests)

What main Board are you using?

What VS1053 Shield and what SdCard Shield (if not same)?

You have evidence of both the SdCard and VS1053 working and yet failing. As you got past the initial check for and initializing of the VS1053, yet you fail to completely read files from the SdCard (the patch) and lock up playing (not no file found). I suspect there is a some conflicts on the SPI. Likely a Chip Select is floating and intermittently/parasiticly enabling causing the problems.

Nearly all cases that I have encountered with such partial working have sourced from SPI collisions. I might guess that your SdCard’s Chipselect is not properly asserting.

[Author]

Posts