RE: HardFault and watchdog?

pabigot — Tue, 24 Mar 2015 18:13:27 GMT

Good; a watchdog that couldn't recover from a hard fault seemed pretty useless.

I generate a hard fault with:

   *(uint32_t *)~0 = 4;

The ultimate cause of the failure I was diagnosing (not directly related to this question) appears to have been a race condition where TASKS_HFCLKSTOP was issued before TASKS_CAL completed, resulting in a situation where LFCLK went out of spec killing both the watchdog and the timer that normally woke the application. This is theory only, consistent with the behavior described for PAN #14 (which doesn't apply to the chips I was using), but the anomalous lock-ups went away when I refactored the request mediation.

RE: HardFault and watchdog?

Stefan Birnir Sverrisson — Tue, 24 Mar 2015 15:39:28 GMT

Thank you for you observation. I have tested this on my nRF51-DK board (third revision nRF51) as well and the watchdog works fine after a hardfault. It is also logical because the watchdog reset is a HW reset, so it is supposed to work at all time.

The only thing I could think of is that you write to the NRF_WDT->CONFIG register to set/clear the HALT bit but accidentally clear the SLEEP bit at the same time. If you clear it, the watchdog will halt while the CPU is asleep. But the question is are you asleep after entering hardfault handler? I can go to sleep after hardfault by implementing a hardfault handler in the application with

void HardFault_Handler(void)  { }

and by going to sleep in the main loop

power_manage();

could that be the case in your application?

How is the hardfault generated in your case?