Hi, I have a question about the WDT documentation in nRF5340 Product Specification v1.6.
Question 1:
The chapter "Reload Criteria" (7.41.1) is maybe a bit ambiguous defining the exact moment when the watchdog counter register is reloaded with the CRV register's value. 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?
One example, considering RR1, RR2 and RR3 are enabled:
Timestamp #1: Trigger watchdog START task
Timestamp #2: RR1 is written for the first time
Timestamp #3: RR2 is written for the first time
Timestamp #4: RR1 is written for the second time ---> Nothing happens, as the register was already written before, but no watchdog reload was triggered in the meantime???
Timestamp #5: RR3 is written for the first time <--- First watchdog reload is triggered here?
Timestamp #6: RR2 is written for the second time
Timestamp #7: RR3 is written for the second time <--- No watchdog reload here, because RR1 is still missing???
Timestamp #8: RR1 is written for the third time <--- Second watchdog reload is triggered here?
Is this assumption correct?
Question 2:
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?
In respect to my example above...
Timestamp #1: Trigger watchdog START task ---> all enabled REQSTATUS bits are set (bit 1, bit 2, bit 3)?
Timestamp #2: RR1 is written for the first time ---> REQSTATUS bit 1 is cleared
Timestamp #3: RR2 is written for the first time ---> REQSTATUS bit 2 is cleared
Timestamp #4: RR1 is written for the second time ---> nothing happens!!!
Timestamp #5: RR3 is written for the first time ---> all REQSTATUS bits are set (bit 1, bit 2, bit 3) because of the watchdog reload event?
Timestamp #6: RR2 is written for the second time ---> REQSTATUS bit 2 is cleared
Timestamp #7: RR3 is written for the second time ---> REQSTATUS bit 3 is cleared
Timestamp #8: RR1 is written for the third time ---> all REQSTATUS bits are set (bit 1, bit 2, bit 3) because of the watchdog reload event?
Is this assumption correct?
Question 3:
On a multi-core SoC, like the nRF5340, does the watchdog reset the whole SoC or only the core it is running on?
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)?
Question 5:
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.
Best regards,
Michael
