What could cause a program to loop back to setup()? [SOLVED]

I'm doing a project now that involves multiple audience interactions, and audio response via a Rogue Robotics MP3 shield.

I'm encountering a very strange bug: whenever I start to play a response audio, the program seems to crash and loop back to the setup routine (it prints version info that is only used in the setup routine).

What could be causing this?

I've established that once I've started sound playback, that control passes back to the main loop. I'm in the process of trying to figure out exactly when it jumps to setup().

I'm using two sets of case statements to process user input, could an extra or misplaced break; cause this problem?

If you somehow broke out of loop() you would reach the end of main() and execution would halt. If you're seeing setup running again it means the microcontroller is crashing and restarting. It could be a hardware or software issue, but you're really going to have to post your code.

It’s very likely you have overloaded memory somehow or run past an array index and possibly over-wrote a return address with zero. Not only does the heap reside in SRAM but the stack does as well. Heap starts at the bottom and fills up, stack starts at the top and varies in length. When your variables overwrite your stack then you crash.

If you use C++ Strings then they like to allocate/deallocate with every change, or if you just like to do the C++ dynamic allocation as habit the heap can quickly and easily end up shotgunned (like a fragmented hard drive only worse) and bloat right up.

You know that UNO only has 2K SRAM? For little things that is plenty. You start throwing around strings or Strings and even using PROGMEM you need to be very sure of what goes where.

Add Serial.println( millis() ); somewhere in the setup function. If the printed value is low, then the chip was reset otherwise somehow setup was called without resetting.

Could be a power issue - how much does the mp3 shield (and speaker(s)) draw and how is the supply configured?

Thank you everyone for your helpful comments!

GoForSmoke nailed it: I'd been using an array of char to build filenames, and sized it to 15 characters. However, at some point I increased the length of the filename prefix by 5 characters, so it would overrun. Sizing my array to 20 characters has solved the problem.

GoForSmoke:
It's very likely you have overloaded memory somehow or run past an array index and possibly over-wrote a return address with zero. Not only does the heap reside in SRAM but the stack does as well. Heap starts at the bottom and fills up, stack starts at the top and varies in length. When your variables overwrite your stack then you crash.

If you use C++ Strings then they like to allocate/deallocate with every change, or if you just like to do the C++ dynamic allocation as habit the heap can quickly and easily end up shotgunned (like a fragmented hard drive only worse) and bloat right up.

You know that UNO only has 2K SRAM? For little things that is plenty. You start throwing around strings or Strings and even using PROGMEM you need to be very sure of what goes where.

Please rename this topic adding [SOLVED]. :slight_smile: