[Michael P. Flaga]

That is annoying. I experience the same problem occasionally. It seams to come and go on its own. I have to believe it is a problem un-related to the SFEMP3Shield library itself. As it occurs without it. I am suspicious that it may be an electrical issue, like a capacitance or race issue on the start up of the SdCard. At times I have seen it help to stuff another card into Arduino and it works. Where sometimes sticking the afflicted card into a Laptop then reading it and then back into the Arduino sometimes cures the problem, not always. Where my initial thought may be wear and tear or corrosion on the SdCard connector.

Let me know of any progress. We may need to advance it to SdCard author.

[Michael P. Flaga]

Look at my GIST example MP3ButtonPlayer.ino
I just threw it together, it does compile and should (???) work. I have not tested it at this moment. Where as it is very simple. And uses the Bounce Library to make Debouncing easy.

[Michael P. Flaga]

prehaps, something like the following, where it is up to you get define getselection();

setup{
  if(!sd.begin(SD_SEL, SPI_HALF_SPEED)) sd.initErrorHalt();
  if(!sd.chdir("/")) sd.errorHalt("sd.chdir");
  MP3player.begin();
  prv_selection = selection;
}

loop{
  selection = getselection();
  if (()selection == 0) and (prv_selection != 0)) {
    MP3player.stopTrack();
    prv_selection = selection;
  }
  else if (selection != prv_selection) {
    MP3player.playTrack(selection);
    prv_selection = selection;
  }
  // do other stuff and then loop back around.
}

[Michael P. Flaga]

The below will repeat track one.


while(1) {
if(!MP3player.playTrack(1)) {
while (MP3player.isPlaying());
MP3player.stopTrack();
}
}


But it will block.

You can actually put

MP3player.playTrack(1);


in the loop and it will attempt to play track one, and if it is still playing it will simply respond with an error code. That can be ignored.

[Michael P. Flaga]

Note that Seeduino MP3’s DREQ pin is not connected to a Arduino Pin that support’s Interrupts. Hence the Error that MP3_DREQINT was undefined, as there is nothing to point it to on the Seeduino MP3 shield.

This is denoted in the support documentation

So the work around is to configure SFEMP3ShieldConfig.h’s line 195 the refill method to use something other than USE_MP3_INTx.

to
#define USE_MP3_REFILL_MEANS USE_MP3_Polled
Then it will compile.

[Michael P. Flaga]

D5 and D10 are both available. Along with A0 through A5, can be used as Digital Input or Output.

[Michael P. Flaga]

There is no need to gracefully terminate SPI transfers, as they are not running in the background, like DMA transfers. Rather the ISR runs in the foreground until completion. They are in while loops.

The ISR is bound within the attachInterrupt(MP3_DREQINT, refill, RISING); function in the SFEMP3Shield::enableRefill() function.

When using the SPI ensure it is properly configured prior to using it. Don’t assume it is the way your code last left it. The SdCard and SFEMP3 libraries both when asserting the chip selects configure the SPI correspondingly. Overwriting what ever its prior state, as used by other code. This provides compatibility with other libraries using the SPI. Where the other libraries should do the same. Otherwise they would mess each other up. Yes, it may appear inefficient, but its compatible.

Note: I see that the SdCard recently added SetBitOrder. the MP3 does not. So that could be an issue, if different.

You could optionally wrap your code between MP3player.pauseDataStream() and MP3player.resumeDataStream() functions. However, this should no longer be needed.

[Michael P. Flaga]

Your pulseLightPin is the same as the SD_SEL, for the SdCard’s Chip Select. Instead change pulseLightPin to A5.

I think you mean; MP3player.playTrack(1) (vs beginTrack). playTrack has a safe guard to be an ignore if a file is already playing.

The “If you get this error…” can only occur during the MP3Player.begin(). And that should only be once. I don’t see another instances. This was a work-a-round warning to make sure the sd.begin was done. It really simply indicates that the SdCard was found but was not started correctly.

So if you really get this after it starts playing and not at boot. It means the unit rebooted. There is no code reason for that. So there may be some hardware thing. likely miss wired. Not sure if your symptoms are accurately portrayed.

I suspect it play’s for a bit then the pulseLightPin = 9, messes with the SdCard. Then it memory crashes, reboots, but the SdCard is messed up and prints the above error.

Otherwise… is this a stock shield? which board and which shield.

[Michael P. Flaga]

It was implied, but may not be obvious that change line 195 of SFEMP3ShieldConfig.h was changed back to…
#define USE_MP3_REFILL_MEANS USE_MP3_INTx
this should allow the interrupt for the motor timers to interrupt during the SdCard Fill.
There has been limited success with this. It may cause other issues. Rumor is that it will work.

[Michael P. Flaga]

Such delays are blocking, until finished preventing the refills of the MP3 from SdCard. It takes time to read the SdCard and it takes time and to service the motors..

you could try adding the following command of sei(); just after line 1696 http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/_s_f_e_m_p3_shield_8cpp_source.html#l01696

…
1696 void SFEMP3Shield::refill() {
1697 sei();
1698 //Serial.println(F(“filling”));
1699
1700 while(digitalRead(MP3_DREQ)){
…

[Michael P. Flaga]

to move the SD Card’s chip select change SFEMP3ShieldConfig.h line 168 to the pin of your choice. Or create a #ifdef to match your circuit.

Whereas, to use other timers does not necessarily prohibit the use of their associated pins for GPIO. The pins are free for other use, unless the timer is configured to be used as its timer function e.g. Generate either a Output Compare or PWM or Input Capture.

Note that the example libraries behavior can be configured to use Timer1 library, in place of Interrupt’s, without changing the pins. by changing SFEMP3ShieldConfig.h line 195

[Michael P. Flaga]

change line 195 of SFEMP3ShieldConfig.h from

#define USE_MP3_REFILL_MEANS USE_MP3_INTx

to

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

This changes the driver not to use Interrupts, but rather the main loop() will

MP3player.available();

will do the refill. This however, requires the main loop() not to be blocking.

[Michael P. Flaga]

The following member functions as shown in MP3Shield_Library_Demo.ino line #185 extract some information from the ID3 tags if present from the file.

void SFEMP3Shield::trackAlbum (char * infobuffer)

void SFEMP3Shield::trackArtist (char * infobuffer)

void SFEMP3Shield::trackTitle (char * infobuffer)

They can be used as examples for extracting other information.

[Michael P. Flaga]

Yes, there is such a plug in. And this library will allow it to be uploaded to the Vdsp. However, the library does not support sending the PCM data on the command channel. That will take quite a bit of work, and as yet has not been implemented.

A quick work a round that I am using, is to have a MIDI file of some beeps. And when a key pad button is pressed, I pause the current file, send the MIDI file and then return to playing the current file. Noting that MIDI files of a single note are short enough to fit in a CONST ARRAY in code. Making it it simple not to have to open a 2nd file and deal with its memory requirements and pointers.

[Michael P. Flaga]

I suspect an interrupt issue. You may want to configure the SFE MP3 library to run in polled mode, rather than interrupt. By changing USE_MP3_REFILL_MEANS to USE_MP3_Polled in SFEMP3ShieldConfig.h

[Author]

Posts