Teensy 4.0 with Audio Shield crashing and damaging micro SD cards

[icmany]

I am using a Teensy 4.0 with a Rev D audio shield. This is a museum exhibit that continuously plays one of 19 tracks (.wav files) stored on a 32GB micro SD card plugged into the audio shield, the track is selected by a visitor. There is a small TFT LCD on the other SPI bus and a timer / counter running on interrupts.
The unit is turned on every morning and off at night. I have found that the CPU is crashing after a few days and damaging the track that was being played so that, once damaged, it crashes every time it reaches this point. The first card this happened to was totally wrecked and could not be read on my PC. The second card has survived many crashes without such damage and when playing the track on the PC, it just stops at the damage point. I reformatted this card and reloaded the files and it worked again - for a while.

Any help gratefully received as I am stumped!

I managed to print the crash report which shows it is running the sound driver which starts with this header:
/* Audio Library for Teensy 3.X * Copyright (c) 2014, Paul Stoffregen, paul@pjrc.com
This is the crash report:
Code was executing from address 0x36B0
16:39:50.088 -> CFSR: 82
16:39:50.088 -> (DACCVIOL) Data Access Violation
16:39:50.088 -> (MMARVALID) Accessed Address: 0x20004E40 (Stack problem)
16:39:50.088 -> Check for stack overflows, array bounds, etc.
16:39:50.088 -> Temperature inside the chip was 40.25 °C

and the address 0x36B0 is in this the middle of this section, I've attached the whole .lst file (zipped):
36a0: 2000 movs r0, #0
36a2: f884 0271 strb.w r0, [r4, #625] ; 0x271
block_right->data[block_offset++] = (msb << 8) | lsb;
36a6: f8b4 0068 ldrh.w r0, [r4, #104] ; 0x68
msb = *p++;
36aa: 46d8 mov r8, fp
block_right->data[block_offset++] = (msb << 8) | lsb;
36ac: 6e67 ldr r7, [r4, #100] ; 0x64
size -= 2;
36ae: 3d02 subs r5, #2
block_right->data[block_offset++] = (msb << 8) | lsb;
36b0: f938 3b02 ldrsh.w r3, [r8], #2
36b4: eb07 0740 add.w r7, r7, r0, lsl #1
36b8: 3001 adds r0, #1
36ba: f8a4 0068 strh.w r0, [r4, #104] ; 0x68
36be: 80bb strh r3, [r7, #4]
if (block_offset >= AUDIO_BLOCK_SAMPLES) {
36c0: f8b4 3068 ldrh.w r3, [r4, #104] ; 0x68
36c4: 2b7f cmp r3, #127 ; 0x7f
36c6: d80f bhi.n 36e8 <AudioPlaySdWav::consume(unsigned long)+0x318>

 

[h4yn0nnym0u5e]

It's not completely obvious how the code is crashing, but one has to assume that it's the result of the corrupted audio file, somehow.

The elements of your post that caught my eye are

The unit is turned on every morning and off at night.

and

that continuously plays one of 19 tracks

so ... the implication is that playback is in progress, and someone just effectively pulls the plug. I can quite see how this will cause SD card corruption: even if you think the code isn't writing to it, all sorts of nasty stuff could happen as the power goes down during a read, such as mangled commands. The stock playback object spends quite a large percentage of the time reading the card, because it only reads 512 bytes at a time.

I'd suggest you start by adding some proper shutdown code to stop playback, prior to powering off, and see if that works. Something like a magic 20th track which actually doesn't play anything, and is unlikely to be accessed by a visitor. It would probably do no harm to include a log file, so that if someone claims "oh yes, we always shut it down properly", and the log file says otherwise, you have evidence...

Assuming a proper shutdown works, you may be able to come up with some hardware to stop playback milliseconds before the power dies, so pulling the plug is no longer fatal - you never know when there will be a power cut.

If the controlled shutdown is not effective, then other fixes are indicated ... quite what, I'm not sure

 

[icmany]

Hi h4yn0nnym0u5e, thank you so much for your prompt reply. Your suggestion makes perfect sense, I really miss having work colleagues to chat to about issues like this. The whole museum power is switched off in one go when it closes every night and no-one goes round to turn off the dozens of AV etc. displays. My exhibit has just one control to choose the track and I don't think a shutdown button would get used. However, the software does fade out the sound after 10 minutes (so as not to make the stewards go mad) and I've added a simple change to not restart the SD card reads if the volume is zero. I think it highly unlikely now that the sound will be playing when the power goes off so I hope this will fix the problem. I've also added a "crash counter" that gets displayed at power on so I'll be able to see if it's now OK.
Thanks again.