Watchdog reset: determining cause

[Mike Voytovich]

Hi,

I'd like to determine the cause of a watchdog reset. I was hoping to utilize the WDT event handler (passed in to nrf_drv_wdt_init()) to record the PC of the application code at the time the watchdog timeout occurred, and save that to a word in uninitialized RAM (I am aware of the time constraints in the handler, and the fact that RAM isn't guaranteed to be retained on a WDT reset).

I'd imagine the application PC code must be saved in a register or pushed on to the stack at some point before the event handler is called.

Do you know where I can find this?

[RK]

If you look at the code for the WDT driver it's very simple, the function you pass in is called directly from the interrupt handler (it's only 4 lines long) so the stack will be set up just as it was when the interrupt was taken (standard Cortex-M interrupt stack) plus whatever was stacked in that function before it called you. That should be quite simple to unwind although you'll have to look at the actual generated assembly to see where on the stack you have to look (you could use the frame pointer but that's usually omitted in release code).