How to analyze the cause of independent Watchdog Reset

[Rookie38]

Hello Community,

I use the IWDG of a STM32F429. My application is relatively simple. Two valves are controlled and data is sent via UART (non-blocking). Nevertheless, I notice at random times a reset of the controller by the watchdog. The window watchdog apparently owns a notification possibility via Early Wakeup Interrupt (EWI). Such a feature does not seem to exist in the IWDG. I wonder what is now available as an option to determine the function with the longest execution time without having to trace everywhere. Is there a way to know where the controller is just before the reset? Does ST already offer some kind of instrumentation?

[Uwe Bonnes · Accepted solution]

SWO trace could watch the programm counter and give a hint what happened last, if sampling frequency is high enough.

[Tesla DeLorean]

Logging the stacked LR in SysTick might provide insight into which routines are candidates for review.

Also instrument Hard Fault and Error Handlers so you can readily tell if it gets into those while(1) loops to die, and save information related to the registers, and source file/line info.

Hard Fault catches a lot of bugs and latent failures in the code.

[Rookie38]

Thank you for the quick reply. Indeed, I find it very good to watch the program counter. With the help of the .map file I should be able to find out the respective functions. But before that, as Tesla already recommended, I will check all handlers with while(1). I seem to have overlooked some of them. If that doesn't work, there seems to be nothing left but to trace the runtimes in the top-down principle. If it doesn't work, I'll get back to you.