RESETREAS issue after WD Reset

RE: RESETREAS issue after WD Reset

Sigurd — Thu, 31 Oct 2019 20:25:27 GMT

[quote user="owain"]In this case can one reinitialise the WDT or will it just run on; possibly expire and reset the system.[/quote]

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.

RE: RESETREAS issue after WD Reset

OwainIncus — Thu, 31 Oct 2019 16:54:08 GMT

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.

RE: RESETREAS issue after WD Reset

Sigurd — Thu, 31 Oct 2019 10:05:37 GMT

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.

RE: RESETREAS issue after WD Reset

OwainIncus — Wed, 30 Oct 2019 17:12:51 GMT

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.

RE: RESETREAS issue after WD Reset

Sigurd — Wed, 30 Oct 2019 16:23:49 GMT

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. "

RE: RESETREAS issue after WD Reset

OwainIncus — Wed, 30 Oct 2019 09:56:18 GMT

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?

RE: RESETREAS issue after WD Reset

Sigurd — Mon, 08 Oct 2018 11:03:15 GMT

Hi,

[quote userid="69482" url="~/f/nordic-q-a/39254/resetreas-issue-after-wd-reset"]After WD reset, I'm looking at RESETREAS register and DOG bit is not high, only PINRESET is high. What am I missing?[/quote]

After PINRESET bit is set, you need to clear the RESETREAS register yourself after you have read the register and taken appropriate actions based on the value. If you don't clear the register, the DOG bit will always be masked out after a PINRESET.

Snippet:

    do_something_based_on_resetreas_value();
    // Action taken. Now clear the flag
    NRF_POWER->RESETREAS = 0xFFFFFFFF;