This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to disable the WDT (watchdog timer)?

After enabling and starting the watchdog timer (RR0), how can it be disabled?

This following code does not work:

NRF_WDT->RREN &= ~(1 << WDT_RREN_RR0_Pos);

Neither does:

NRF_WDT->POWER = 0;

Edit: I'm using a Rev G0 chip.

Parents
  • I don't believe this is an errata item. Rather, it appears to be a designed in behavior. If you look at the Reference Manual (2.0) section 11.1.6.8 on reset behaviors, the WDT is preserved on a soft reset. It requires one of the following reset types to be cleared on reset: power, pin, brownout or watchdog.

    It could be more clearly stated in the watchdog section of the document as well, but it appears to be design intent.

Reply
  • I don't believe this is an errata item. Rather, it appears to be a designed in behavior. If you look at the Reference Manual (2.0) section 11.1.6.8 on reset behaviors, the WDT is preserved on a soft reset. It requires one of the following reset types to be cleared on reset: power, pin, brownout or watchdog.

    It could be more clearly stated in the watchdog section of the document as well, but it appears to be design intent.

Children
  • Also note the following statement from the watchdog section of the reference manual: "The watchdog must be configured before it is started. After it is started, the watchdog’s configuration registers, which comprises registers CRV, RREN, and CONFIG, will be blocked for further configuration. "

  • All I did was add a service of the WDT in the wait for events loop and also when the loop exits so that the WDT has its full amount of time while the system restarts. Just put this line in two spots in your wait_for_events function:

    NRF_WDT->RR[0] = WDT_RR_RR_Reload;
    
  • Yes, it''s a brilliant design they chose to reuse in the nRF52 as well. When doing FW upgrade and switching to the bootloader you can't disable the WD. Of course you can chose to stop feeding the WD and wait for the timeout reset; but then the content of the GPREGRET register is lost and hence can't be used to stop in the bootloader. Hence your best option is to let the bootloader feed all the RR registers.

    Now when you enter the upgraded application you may wish to configure the WDT differently - but you can't. So one option is to let the WDT reset the system again. If you are logging WDT resets as anomalies you need some mechanism to remember the latest WDT reset was a disarm reset and shouldn't be logged. You need to describe this, make test cases and demonstrates that i really works.

    I'd much appreciate writing code that directly benefits our customers instead.

Related