RE: nRF5340 Watchdog (WDT) Specification

Sigurd — Mon, 03 Mar 2025 12:23:21 GMT

Hi!

[quote user=""] Is my assumption correct, that the watchdog is reloaded when the last enabled RR value is written, even if there is a larger delay within the write operations? And all RR registers are reset at the exact moment when the watchdog reload takes place?[/quote]

Correct. If the watchdog is configured to use more than one reload request register,
all these registers must be written to at least once before the watchdog is reloaded.

[quote user=""]Concerning the REQSTATUS register, does this register represent the condensed information which RR has already requested a reload, and upon watchdog reload, all bits are reset to 0?[/quote]

In this register you will see "1" if the register is enabled(RREN) and has not been "kicked"(RR set), and "0" if register not enabled(RREN) or has been "kicked"(RR set).

[quote user=""]On a multi-core SoC, like the nRF5340, does the watchdog reset the whole SoC or only the core it is running on?[/quote]

See this link:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/reset/doc/reset.html#ariaid-title7

[quote user=""]

Question 4:

The nRF5340's application core has two WDT instances (WDT0, WDT1). Is on of the WDT instances used by the NRF Connect SDK or Zephyr? It seems like WDT0 is activated in the device tree automatically (also when I create a new board definition with the VS Code tool that doesn't specify any project-specific WDT related properties). Or are both WDT instances available for NRFX or bare metal programming (e.g. using two different timeouts for real-time interrupt routines and low level handler routines)?

[/quote]

Looks like by default wdt app instance 0 is enabled. instance 1 is disabled(i.e. free to use in "bare-metal" or if you want to implement your own driver. )

https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi#L337

[quote user=""]Is there a Zephyr driver (and sample project) that just uses the hardware watchdog, without any task-based software-watchdog running in the background (e.g. when real-time behavior is necessary)? Or would it be more feasible to use the watchdog simply with bare metal programming? Implementing a project-specific driver outside of Zephyr should be very straightforward with this great hardware design.[/quote]

This is how underlaying driver looks like: https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/drivers/watchdog/wdt_nrfx.c

This is the API: https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/drivers/watchdog.h

If you want to use task_wdt subsys: https://github.com/nrfconnect/sdk-zephyr/tree/main/subsys/task_wdt

or implement your own way to call wdt_feed(), e.g. like done here: https://github.com/nrfconnect/sdk-nrf/blob/main/applications/nrf_desktop/src/modules/watchdog.c

is up-to you.