RESETREAS issue after WD Reset

[Dinkin Uri]

Hi, I am using nRF5_SDK_15.0.0_a53641a.

I'm using code below to start WD and I'm not feeding WD.

NRF_WDT->CONFIG = (WDT_CONFIG_HALT_Pause << WDT_CONFIG_HALT_Pos) | ( WDT_CONFIG_SLEEP_Run << WDT_CONFIG_SLEEP_Pos);
NRF_WDT->CRV = 10*32768;             // 10sec timout
NRF_WDT->RREN |= WDT_RREN_RR0_Msk;  // Enable reload register 0
NRF_WDT->TASKS_START = 1;           // Start the Watchdog timer

After WD reset, I'm looking at RESETREAS register and DOG bit is not high, only PINRESET is high. 

What am I missing?

I found that in in system_nrf52840.c there is errata136 that resets all bits but PINRESET, when I remove that code it works fine. Why does this errata exist and if I need it?

[OwainIncus]

I too have stumbled upon this problem.

I am getting a genuine watchdog reset but errata136 is wiping the status from the watchodg register.

I was relyng on this as designed to log reset reasons; why is this bit being cleared by this errata.
And when is the bug being fixed so we may use this status register properly?

[Sigurd]

Hi Owain,

See this post. Quote:

"Are you clearing the RESETREAS register after you read it out on startup? The reason I ask is that workaround for errata 136 implemented in system_nrf52.c will clear the other bits if the PINRESET bit is set. In other words, you can expect to see this behavior if you don't clear the register, and you have done a pinreset since the last power-on reset. "

[OwainIncus]

I have done nothing with the RESETREAS rgeister. I just see its contents using my debugger.

Scenario I have is we are going through our bootrom; starting our application and I am seeing an unexpected reset. We don't start the watchdog until we start our application.

Selecting our application project I was seeing a restart and NOT hitting any fault handler or NVIC reset breakpoint; so I suspected a watchdog; hence setting a breakpoint in the bootrom early on before the errata stuff is processed. In this situation I see the DOG and Reset bits set. If I restart via the debugger then I only the Reset bit.

I may only be seeing this issue when rhe device is connected on a segger JLink. Selecting our application project I was seeing a restart and not hitting any fault handler breakpoint; so I suspected a watchdog. I don't understand this.

[Sigurd]

Please be aware of what sources that are resetting, and not resetting the watchdog. See this link.

Also be aware of how the watchdog CONFIG register is set. See this link 

If you are still having issues with this, please create a new support case. See this link.

[OwainIncus]

So NVIC System Reset which does a reset over AICR is a soft reset and does not reset the WDT.
In this case can one reinitialise the WDT or will it just run on; possibly expire and reset the system.

So when we do a DFU, from our application code; which transfers control to the bootrom for the DFU this must be a forced watchdog reset; otherwise we would be seeing WD timeouts ewhen doing DFU which is not the case.

This may explain some of the unexpected restarts we have been seeing occasionally.

[Sigurd]

OwainIncus said:

In this case can one reinitialise the WDT or will it just run on; possibly expire and reset the system.

 The WDT will still be running. See this post

If the WDT is enabled by the application, then it must be feed by the bootloader during the DFU process to avoid the device to reset prematurely. Watchdog support to the bootloader code was added in SDK 15.0 (with a bug-fix for this in SDK 15.2). So for SDK 15, if the application had enabled watchdog before resetting to the bootloader, it is automatically fed in the bootloader. If you are using an older SDK version, take a look at e.g. this post.