RESETREAS DOG without WDT Handler Firing

RE: RESETREAS DOG without WDT Handler Firing

Vidar Berg — Mon, 03 Aug 2020 06:35:16 GMT

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

RE: RESETREAS DOG without WDT Handler Firing

jacksong — Mon, 03 Aug 2020 03:41:39 GMT

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

RE: RESETREAS DOG without WDT Handler Firing

Vidar Berg — Thu, 23 May 2019 13:03:23 GMT

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);

RE: RESETREAS DOG without WDT Handler Firing

JeffW — Thu, 23 May 2019 12:49:58 GMT

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.

RE: RESETREAS DOG without WDT Handler Firing

JeffW — Wed, 22 May 2019 13:42:18 GMT

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.

RE: RESETREAS DOG without WDT Handler Firing

Vidar Berg — Wed, 22 May 2019 13:15:50 GMT

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.

RE: RESETREAS DOG without WDT Handler Firing

lev — Tue, 21 May 2019 15:40:36 GMT

Maybe this behaviour is caused by the debugger. See https://devzone.nordicsemi.com/f/nordic-q-a/15677/why-does-nrf52-hrs-sdk11-example-sd_power_off-return-6.