MCU-PLUS-SDK-AM243X: DWWD does trigger unexpectedly

Felix Heil

Tool/software:

Hello,

we are using the DWWD on the Sitara.

Our application is pretty simple: We have a task and the watchdog. The task clears the watchdog in a period that is shorter than the period of the watchdog. So the trigger does never occur.

The watchdog is deactivated for debug-builds and activated for release builds. If we want to debug a release-build we run into some problems since the watchdog triggers in some scenarios:

if a release-build is already on the device and a release-build is loaded via CCS: Watchdog triggers immediataley after Watchdog_clear()
if a debug-build is already on the device and a release-build is loaded first via CCS: works.
if afterwards a a release-build is loaded again: Watchdog triggers immediately.

So it seems that if the Watchdog is configured once, it will directly trigger and I do not know why.

We also wrote our own Watchdog driver which utilizes the watchdog-functionality but I oriented at the examples and the TRM. The only thing I did contrary to the examples is the clear, since the TRM says:
"The RTI_INTR_WWD interrupt handler needs to clear the watchdog violation status flag(s) and then service the watchdog by writing the correct sequence in the watchdog key RTI_WDKEY register"
But the examples did it the other way round. nevertheless the order, the problem persists.

In general we could say that this is the code that is used for our watchdog:

The BFWatchdog_open is the same as the Watchdog_open, except it does not take an array index but the config itself.

We also use it as an fiq-interrupt, because we noticed a HwiP_disable also would block the watchdog-interrupt, which it shouldn't and nmi is not available that way on the am243x:

MCU-PLUS-SDK-AM243X: RTI_DWWD no non-maskable interrupt? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

We use the watchdog instance 8, so TISCI_DEV_RTI8/WATCHDOG_INST_ID_8 on the mcu0_0. and the 9 corresponding on the mcu0_1.

so, if we have a release-build already on the device, we come here:

WDSTATUS looks nice.

And now as soon as the Watchdog_clear is returning:

The WDSTATUS somehow gets set?

CCS does not use the v1-file, but the v0, that's why the line does not match the code on the left.
But we always experience that and that makes it impossible to debug a board which has a release-firmware already on it. So, a firmware which already initialized the Watchdog once.

Also our watchdog-period is set to 16 seconds! So it's not like I were in a breakpoint for too long or smth. it immediately occurs after start as soon as the Watchdog is created.

Is there something else that is not documented or I did just read over, which needs to be done to make this work?

This is really needed to be able to debug our release-firmware in some cases. and with that it's just not possible.

Best regards

Felix

19 hours ago

0 Swargam Anil 44 minutes ago

TI__Mastermind 45896 points

Hello Felix,

In AM64x devices, the watchdog timer (WDT) can only be configured once after reset. Once you set the watchdog time-period, re-configuring it later will not overwrite the existing configuration.

In your scenario:

If you already flashed an image that configured the WDT with period X, and then you load another image from CCS with a different period, the WDT peripheral will retain the first period and ignore the new configuration.
This is expected behaviour on AM64x — the WDT parameters are latched after the first configuration until the device is reset.

Another important point: AM64x watchdog does not support auto-reset of the SoC. If we wanted to make soc Reset after the wdt is expired then we need to be integrated wdt with ESM module .

If the SoC is running in an exception state (for example, due to a fault), then even if the WDT expires, the interrupt will not be serviced, and no reset will be triggered.
This means the system can appear “stuck” if you rely only on the watchdog interrupt.

To fix this, the recommendation is to configure the WDT with ESM to resets the SoC after expiry. This ensures that even if the CPU is stuck in an exception or cannot handle interrupts, the watchdog will still recover the system.

Please also review the WDT FAQ documents linked below for:

How to configure the watchdog for SoC reset mode
Debugging watchdog issues on AM64x

[FAQ] AM64X/ AM62X : How to Reset the SOC when WDT timer expires in AM64X and AM62X?

[FAQ] AM6442: Watchdog debug and configuration guide for all SITARA AM6X MPU devices

Regards,

Anil.