It’s Friday around 4 PM. You’ve been on a productivity tear and are getting to
wrap up for the week when, all of a sudden, things go off the rails. Logging has
stopped entirely with no clues to the problem, your LED has stopped blinking,
and even the debug CLI you painstakingly coded has stopped responding to any of
your commands. “But I wasn’t even making a complicated change!” you yell into
the void. You’ve thoroughly bricked your firmware, and none of the usual safety
nets you’ve set for yourself are telling you why!
This is a companion discussion topic for the original entry at https://interrupt.memfault.com/blog/debugging-steps
Awesome article, bookmarking it to steal these next time I’m ripping my hair out. The DCache point is timely because I was recently bitten by that moving from an M4 to M7…
Another thing I have gotten in a habit of doing for spurious corruption/reboots is disabling watchdog timers and seeing if the issue goes away. Especially if the issue happens with high CPU usage, or during long running operations like OTA/reflashes. Also check your datasheets and debugger config to see if it pauses counters/timers after hitting a breakpoint. Otherwise you might get an avalanche of interrupts when stepping.
And glad to see you’re still crushing after college!