Watchdog isn't disabled at boot when CONFIG_WDT_DISABLE_AT_BOOT=y

[douglas.malnati]

Windows 11, WSL2, NCS 2, VSCode

I want to be able to reboot my chip without the watchdog automatically being enabled on boot.

I cannot seem to disable it through the API (-PERM return value).

This happens when I  sys_reboot(SYS_REBOOT_COLD) or NVIC_SystemReset().

My prj.conf has:

CONFIG_WATCHDOG=y

CONFIG_NRFX_WDT0=y

CONFIG_WDT_DISABLE_AT_BOOT=y

Is there something I'm misunderstanding?

How can I get this to work?

Thanks.

[Sigurd Hellesvik]

Hi,

Started watchdog cannot be stopped on nRF devices.

For more information on the nRF watchdog, see nRF52840: WDT — Watchdog timer.

Seeing this, I think that the CONFIG_WDT_DISABLE_AT_BOOT should not work for CONFIG_WDT_NRFX, and I have suggested this to our developers.

Regards,
Sigurd Hellesvik

[douglas.malnati]

Hi, not sure what you mean "should not work," since I'm saying it doesn't work.

I implemented this using the zephyr library, but never got any callbacks on the interrupt callback, not sure why.  I see INTENSET disables interrupts.  Would disabling that prevent the watchdog from firing?

How can I improve my situation?  Can I change the remaining time on the watchdog to be 0 somehow to cause an instant reboot-via-watchdog?  Something else?

How does anyone else deal with this problem?

Thanks.

[Sigurd Hellesvik]

douglas.malnati said:

Hi, not sure what you mean "should not work," since I'm saying it doesn't work.

To clarify: If the nrfx drivers do not support disabling WDT, you should get a warning or error when setting CONFIG_WDT_DISABLE_AT_BOOT.

douglas.malnati said:

I implemented this using the zephyr library, but never got any callbacks on the interrupt callback, not sure why.  I see INTENSET disables interrupts.  Would disabling that prevent the watchdog from firing?

No.

From nRF52840: WDT — Watchdog timer:

"See Reset for more information about reset sources. If the watchdog is configured to generate an interrupt on the TIMEOUT event, the watchdog reset will be postponed with two 32.768 kHz clock cycles after the TIMEOUT event has been generated. Once the TIMEOUT event has been generated, the impending watchdog reset will always be effectuated. "

In other words: You get two cycles to react before the reset, but it will still trigger.

douglas.malnati said:

How can I improve my situation?  Can I change the remaining time on the watchdog to be 0 somehow to cause an instant reboot-via-watchdog?  Something else?

How does anyone else deal with this problem?

I hope that I can give some tips here, but first, I think it would be useful to know the following:

Why is it a problem that the watchdog is active after a reset?

Regards,
Sigurd Hellesvik

[douglas.malnati]

Sigurd Hellesvik said:

Why is it a problem that the watchdog is active after a reset?

Because when the device restarts, it will run for a short period of time, and then restart again, but not again after that.

I am exposing the ability to reboot the system from application to either restart the app, or to restart into bootloader.  The bootloader doesn't even know about the watchdog, and my startup app logic doesn't either.

In both cases, the restart happens, but then the device restarts again.  It's a bad user experience and makes the code more complex to have to try to detect which start-up sequence you're in (eg did I restart on purpose or the watchdog got me).

Having a long watchdog timer won't work because the bootloader waits for user input.

Thanks.

[Sigurd Hellesvik]

We use MCUboot as our default bootloader in the nRF Connect SDK.
I do not know which bootloader you use, so I will use this as an example.

MCUboot has a CONFIG_BOOT_WATCHDOG_FEED to "Feed the watchdog while doing swap".
So a solution here would be to add watchdog feeding to the bootloader while waiting for the user to input data.

Alternatively; "The watchdog can be paused during long CPU sleep periods for low power applications and when the debugger has halted the CPU." (WDT docs)
You can put the CPU to sleep when waiting for user input if this option is enabled.

But yea, since our WDT peripheral can not be disabled there is no way to disable it for only one boot. So you have to add some extra functionality to handle your case.

Regards,
Sigurd Hellesvik

[douglas.malnati]

Thanks Sigurd, that's a last-ditch approach for sure.  I'm surprised this is such a troublesome peripheral.

Can you help me understand part of the spec meaning?

This talks about starting "running again" - after a watchdog reset also?  What is the meaning of being able to configure those registers at that time?  Doesn't this mean you can set up the watchdog on startup?

Thanks.

[Sigurd Hellesvik]

Some reset-causes for the nRF will also reset the WDT peripheral. See the table below:

If the WDT is reset, you will have to manually start it again.
So, you can disable the WDT by resetting the nRF Chip in either of these ways.

Side note: The WDT peripheral in our nRF5340 has functionality for stopping the watchdog.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

https://github.com/zephyrproject-rtos/zephyr/pull/73091