Firmware crashing randomly when using Adafruit Music Maker featherwing

Troubleshooting
1

I'm currently using the 1.21 firmware on the Xenon, and while stability seems to have improved I'm still getting random firmware crashes when playing long files through the Adafruit Music Maker featherwing.

I've seen both sets of 10 and 14 red blinks.
14 blinks seems to indicate

Since 1.2.0* Other heap-related error, such as allocating memory from an ISR

My code is based on the ParticleTest.ino that comes with the VS1053 library
I'm setting things up with an interrupt. I'm doing other stuff so can't afford to have the file player hog all resources. Everything works file, except that I get very random firmware crashes as stated.

  if (musicPlayer.useInterrupt(VS1053_FILEPLAYER_PIN_INT))
  {
  }
  else {
    Log.info("DREQ pin is not an interrupt pin");
  }

I'm wondering if there's anything that I can do to fix or debug this? My sound file is around 3-4mins long I think.

2

Any thoughts @ScruffR or @peekay123 ?

EDIT: It seems that most of the time the crash occurs after about a minute or two of audio playback...so it takes a while. Then once it has crashed once, it has trouble rebooting cleanly, getting errors like

"Failed to load session data from persistent storage"

even if I power it off. Most of the error led messages involve 14 blinks too.

3

I’ll have to try.
Does this happen with the completely unaltered ParticleTest example too?
Can you provide the meta data for your MP3 file(s)?

4

I’ll try ParticleTest and get back to you. I currently have an .ogg file (I hold the copyright so I can share it) which previously was an mp3 but I read on the VS1053 forums that ogg is apparently better supported.

5

OK so I tried the basic ParticleTest and the file plays through longer (I had some neopixel code that was causing issues) but eventually it stalls.

Here’s the file I’m testing:

6

@pierrep, you may also want to look at this thread:

Gen3 devices run at 64MHz and use a different DeviceOS (under the hood) than the Photon or Electron. The ISR handler reads data from the SD card and writes to the Music Maker which can be heavy. You may want to try with Mesh.off() and commenting out the Particle.function() calls.

1 Like
7

Aha, thanks @peekay123 that’s very interesting. The problem is that I want to create a mesh network of audio capable devices…so perhaps I’m going to have to look at an alternate device. I have some DFplayer mini clones, might see if I can integrate them. It’s annoying though because I invested in a whole bunch of these devices, but maybe I’ll just switch the MIDI capabilities of the board on instead

8

Just to resurrect this, I tried using the ParticleTest code then triggering audio playback by calling:

int        trackNumber      = 5;
bool       needStart        = true;

I also called Mesh.off() and commented out any Particle.function callls,
The firmware still crashes after a random time, just like before. So it doesn’t appear that the problem is networking related.

EDIT: just for reference, audio playback using musicPlayer.playFullFile() works fine.

9

Quick question @peekay123, I noticed in the Adafruit_VS1053 library that the SPI clock speed is being set via
SPI.setClockDivider(SPI_CLOCK_DIV128);

On the Arduino versions of this chip, I’ve seen code that uses a clock divider of 16:

So given the Arduino is typically at 16MHz, and a divider of 16 would bring the SPI clock speed to 1MHz, shouldn’t we be using SPI_CLOCK_DIV64 for the 64MHz gen3 chip?

I’ve tried this and it seems to have given me some stability in the sample playback…still testing though.

I’ve no idea what I’m doing here, just experimenting…any input would be helpful!

10

@pierrep, the clock “tree” for Arduinos is different than those on the STM32 and the nRF52840. The library was written before SPISettings() and SPITransaction() commands were available. On the Photon, using SPI which runs at 30MHz, DIV128 produces a 234KHz clock.

Looking at the latest Adafruit library, it seems that a lower 250KHz speed is used for commands while an 8MHz speed is used for data. If I can find the time, I will update my library to include the latest changes.

which may have been the only working clock rate. The library should be adapted to use the newer SPI commands so the data rate can be set to 1MHz (eg SPISettings(1*MHz, MSBFIRST, SPI_MODE0)).

11

OK thanks for the clarification. Turns out the increased stability was not due to the SPI settings but rather that the device was failing to connect to the cloud. Seems like Mesh.off() is not enough to provide stability either, but completely disconnecting or using MANUAL mode works, and then interrupt based audio works fine. If I delay playback until after the cloud has connected, audio works for a while, then freezes, although the firmware doesn’t crash and the processor appears to be up and running fine.

2 Likes
12

@pierrep, that's an important nugget to share! Thanks!