They’re described in paragraph 6.6 of the PRM itself.
On Toradex KB I find this article that doesn’t refer to the Plus (i.MX 8M Mini is there).
And so I suppose one of the watchdog timers is (can be) used by Linux that runs on Cortex-A (A53).
is this watchdog timer used by TorizonOS?
which is the timer used for Linux (WDOG1, WDOG2 or WDOG3)?
in PRM I see that pin B6 (GPIO1_IO02) can be configured to be triggered for WDOG1_WDOG_ANY or WDOG1_WDOG_B. Is this pin available on Verdin X1 connector? It doesn’t seem so from the datasheet, but I need a confirmation.
In my project I use Cortex-M too and so I need to use a dedicated watchdog for it.
The wdog example from NXP SDK uses WDOG3 for Cortex-M.
Can I use it on Verdin SoM too?
Does this resets Cortex-M only?
Is the Cortex-M firmware preserved? Or should the Cortex-A take care of reloading it?
I would assume yes, the standard device-trees remain the same in Torizon
in PRM I see that pin B6 (GPIO1_IO02) can be configured to be triggered for WDOG1_WDOG_ANY or WDOG1_WDOG_B. Is this pin available on Verdin X1 connector? It doesn’t seem so from the datasheet, but I need a confirmation.
The extra flag fsl,ext-reset-output; on the watchdog device-tree node means that the watchdog will not generate a software reset, but will instead assert the WDOG_B pin. This pin is not available on the edge connector, it’s connected to the PMIC.
Can I use it on Verdin SoM too?
Does this resets Cortex-M only?
As you can see on the RM, there are options to configure WDOG3 to either reset only the M7 or the full system:
Is the Cortex-M firmware preserved? Or should the Cortex-A take care of reloading it?
I think this would need to be tested and I imagine it could also depend on which memory you’re linking your M7 code to. If resetting only the M7 core, I would think the memories (like TCM) should not be reset with it because the entire chip is not going through a reset. So it could be that the M7 would just start running as if the firmware was on flash. The NXP WDOG example you pointed seems to also point in this direction.
sorry for this late answer, but I had to delay this investigation due to high-priority tasks.
Now it’s time to jump back into it.
I tried to understand what I read in the manual and I try to summarize here:
As far as I understand two different signals are involved with the watchdog:
WDOG_RESET_B_DEB which is internal to the chip
WDOG_B which is external (i.e., it can be routed to a pin)
The internal WDOG_RESET_B_DEB is an input to the System Reset Controller (SRC) to decide what to do with it:
Looking into Linux imx2_wdt.c driver I see that ext-reset-output sets wdev->ext_reset flag
And this flag is used later
to enable or disable WDT (in the source file it’s called WRE but it’s the bit(3) and so it’s WDT for iMX8MP)
And later on
to set either SRS or WDA (but not both of them).
But as I read in the manual, if WDT (or WRE as called ikn the source file) is set:
NOTE: There is no effect on WDOG_RESET_B_DEB (WDOG Reset) upon writing on this bit. WDOG_B gets asserted along with WDOG_RESET_B_DEB if this bit is set.
And so setting ext-reset-output both WDOG_RESET_B_DEB and WDOG_B gest asserted together.
And since WDOG_B is routed to the PMIC on Verdin, the full chip is reset.
I understand that if I clear WDT, WDOG_B is not set by watchdog timeout (but it can be set by software, if needed).
I suspect that in this case the internal WDOG_RESET_B_DEB is generated as an input to SRC, and I can configure it to have M7 core reset only (setting SRC_M7RCR).
Does this make sense?
