Troubleshooting when a firmware seems to hang even before setup() or USB?

[doctea]

I've been attempting to update from Teensy 4.17 to any later version, but somehow the resulting firmware crashes the Teensy before reaching setup() and without ever appearing as a USB device on the host, so I'm at a loss how to start troubleshooting it.

Depending on the Teensy version I try (4.18, 5.0), and other tweaks I try to make to the build environment and my code, I run into different behaviours:-

- 9 blinks of the LED (" However, a software crash resulting in hard fault or CPU lockup (typically very early in startup) can result in this error.")
- Nothing appears in USB devices on the host at all
- Teensy appears in USB devices, but goes into its continuous timeout+reboot cycle (adding "while(!Serial);" to the start of setup() makes no difference to this, making me think that we are crashing before setup() gets run?)

As far as I know, CrashReport can't be used to get any further clues about the cause here, since the crash occurs before I get control and I'm unable to get any serial communication.

Reverting to using 4.17 works fine.

Its a very large project, and although I can turn off many features at compile time I've not been able to find anything that gets the boot working any further.

Its developed in platformio, which I know is frowned upon and makes it hard to offer support, but I'm really stuck at knowing what my next steps could be to allow me to find the cause and update my teensyduino platform.

Any advice please?

Full project code is at the link above (if anyone wants to give it a go then I can try to help you get the correct libraries installed so that it'll build), or I can provide working / non-working firmware binaries if that's any use.

Thanks!

 

[jmarsh]

If you use C++ it may be crashing somewhere in a constructor for a static object. Besides commenting them out, you can use the builtin LED to see which ones are completing successfully.

 

[doctea]

Ooh, I hadn't thought of that, thanks. Are there any neat tricks I could use to find likely suspects in my code/libraries? Almost everything I do in my own code is created with new during setup, so this will be a bit of a needle-haystack situation...

 

[jmarsh]

Well, there is one other longshot...
The crash report that gets written when a program faults is located right at the end of RAM2. So in theory, if nothing else touches that memory in between (and the device stays powered), you could upload a new sketch that does nothing except print the existing CrashReport and use that information to trace the error in the first program.