stm32 f4xxx: how did I end up in reset_handler?

[dieter 123]

Posted on June 29, 2017 at 17:56

Hi

In which cortex registers would I see where this reset originated from?

I have a breakpoint in the CUBEMX resethandler.Which gets trigerred after some seconds.

My Project: UDP loopback LWIP + freertos. The reset happens after couple of minutes.

Link register says 0xfffffffff

is there any other register to have a look?

[Danish1]

Posted on June 29, 2017 at 21:36

You need to look at RCC->CSR (RCC clock control & status register).

But (and this is important) once your application is up and running (and you have read RCC->CSR and written it to your logging system) you need to clear it by or-ing it with RCC_CSR_RMVF to it so that it captures the cause of the next reset. Otherwise it will tell you all the causes of reset since it was last cleared, not just the most-recent cause of reset.

Hope this helps,

Danish

[Tesla DeLorean]

Posted on June 30, 2017 at 01:56

There is a reset reason register, might be helpful for a watchdog or standby.

The processor registers aren't going to be much use after reset, but you could inspect the stack, or write check-point values into RAM which you can inspect upon failure.

The Hard Fault Handler tends to catch a log of egregious failures, have a good handler there that dump state. File the stack with a hard pattern like 0xCDCDCDCD or 0xE5E5E5E5 that a) you can recognize depth issues with, and b) will likely hard fault if popped into the PC, jumped too, or used as a pointer.

Output telemetry via USART or SWV so you understand the flow around the failure, these can be verbose, or a single unique character. Sanity check malloc() returns. Monitor the Heap. Check the Stack Depth periodically.