Reply To: Problems with Sparkfun MP3 straight from the box

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