RESETREAS DOG without WDT Handler Firing

[JeffW]

SDK 15.2, nrf52840 SD 6.1

I'm having an issue where a reset with RESETREAS DOG 0x02 is not coming through the WDT handler before executing reset.
I can force this reset by jumping into a while(1) spin loop, but the WDT expired handler does not fire before the jump to 0 reset.
The code resets, and the reset reason is watchdog, however my breakpoint and routine in wdt_event_handler are not executed before the reset. (I make sure to clear the reason after each reboot)
I also made sure APP_ERROR_CHECK is not executed either.

What is the path of this execution? Is this a valid watchdog reset, or am I looking in the wrong place?
Does the soft device not being able to run in the while loop cause the reset? The breakpoint that happens at the reset instruction does not give any context. 

Any help/insight would be appreciated,
Jeff

[Vidar Berg]

Hi Jeff,

Can you try the WDT example in \nRF5_SDK_15.2.0_9412b96\examples\peripheral\wdt to see if you get the same result? I did not manage to reproduce this behavior here. I placed a breakpoint in the wdt_event_handler() and observed that the CPU was halted before the WD had time to reset. 

[JeffW]

Vidar, 

I appreciate you running tests!
The WDT example works as you describes, but this result varies from my real application experience.
Do you know of any interaction with the soft device enabled where a while(1) loop will trigger a WDT reset reason without coming through the WDT handler?

It's strange to me, but maybe I'm missing something at a low level.
--Jeff

Edit: Ran a few tests, my breakpoint and log/flush in the WDT_handler weren't being spit out in the RTT before reset. I am running a few more tests on this.

[JeffW]

After trying a few things this is my new experience:
I can put a while(1) loop anywhere in main after the WDT is enabled, and it falls through the WDT handler before reset as expected. 
But if I send a NUS command that schedules (app_sched_event_put) a while(1) loop, it does not seem to go through the WDT handler before resetting.

[Vidar Berg]

Ah, the WDT ISR is probably being blocked by another interrupt of the same or higher priority. Please try to set it to have the highest priority after enabling the Softdevice:

NVIC_SetPriority(WDT_IRQn, 0);

[jacksong]

Hi,

I ran into the same problem, and after patch this code, problem still.

test with:

set nrf_drv_wdt_init with interrupt_priority 0 will trigger a ASSERT ERROR by INTERRUPT_PRIORITY_IS_VALID(pri)

so, try to insert NVIC_SetPriority(WDT_IRQn, 0); between wdt_init and wdt_enable

But, test result is can't catch wdt_timeout_hanlder in debug(just Reset)

Is there a better answer or tutorial, currently updated

Thand you advance

[Vidar Berg]

Interrupt priority 0 is reserved to the Softdevice, hence the assertion. But you can work around this by calling 'NVIC_SetPriority(WDT_IRQn, 0);' after enabling the Softdevice.

As a test to confirm if the WD callback is indeed blocked by another interrupt, please try to add an infinite loop after 'wdt_enable' in main context, then check again if the WD callback doesn't come through.

e.g.

int main()

{

...

wdt_enable();

for(;;); // Wait here until the WD times out

..