Recently, I have been working on configuring the watchdog timers during the early boot stages, specifically in MB1 and MB2. I’m using Jetson AGX Orin (L4T R36.4.3) Based on the documentation:
the watchdog configuration appears to rely on the following parameters:
wdt_enable: Enables the BPMP watchdog 5th-expiry during MB1/MB2 execution (boolean)
wdt_period_secs: Defines the watchdog timeout period (in seconds per expiry)
I attempted to validate this configuration by modifying these variables in the MB1 misc BCT file (enabling/disabling the watchdog and adjusting the timeout). However, I do not observe any change in behavior. The MB1/MB2 logs suggest that the watchdog remains enabled regardless of the wdt_enable value, whereas the documentation implies it should be disabled when set to 0.
}
Additionally, I noticed another parameter, enable_wdt, in the misc section, which appears in newer versions (e.g., r38.2) and is also referenced in this forum discussion:
However, setting enable_wdt = 1 causes the system to crash during flashing.
Given this, I would like to clarify the following points:
Is it actually possible to configure the watchdog behavior in MB1 and MB2, or is it always enabled by default?
Which parameter should be used to control it: wdt_enable or enable_wdt?
Is MB2 protected by the BPMP watchdog or by the CCPLEX watchdog?
Are you using the devkit or custom board for AGX Orin?
On L4T R36.4.3, enable_wdt is the main control knob, not debug.wdt_enable. If needed, also try disable_wdt_globally = <1>.
R36.4.3 also has an early-boot issue where WDT may stay active before MB1 settings fully apply, which can explain the unchanged behavior or flashing crash.
Also, MB1 runs on BPMP, while normal MB2 boot/flashing runs on CCPLEX.
I am using a custom board based on the Jetson AGX Orin.
I tried enabling the watchdog by setting enable_wdt to 1 (it is 0 by default). However, after making this change, I encounter an error during the flashing process:
Enabling enable_wdt=1 by itself is not expected to make flashing fail.
Based on the platform behavior, this looks more like a custom-board bring-up/configuration issue exposed during the flashing path, rather than the watchdog setting alone.
Please verify your custom board MB1/MB2 BCT, ODM data, and flashing configuration, especially whether MB2 BCT was updated correctly for your carrier board design (for example, EEPROM-related handling if your board differs from the reference design).
Also, please capture the full flash log and check the first error before tegradevflash_v2 --create returns value 3.
As an isolation step, please try flashing only A_MB1_BCT first to confirm whether the watchdog-related BCT change itself is the trigger.
Yes, I’ve tested this using sudo and by updating only the partition. Also, our manufacturer does not seem to use the EEPROM.
When updating only the A_MB1_BCT partition (instead of the full image), it appears to work. During the MB1 boot phase, it looks like the system is attempting to re-enable the watchdog timer (WDT).
By default, the variable is set to:
enable_wdt = <0>
In this case, I see the trace:
Task: Enable WDT 5th expiry
However, when I update only this partition with:
enable_wdt = <1>
I observe:
Task: Enable WDT 5th expiry
Re-Enabling WDT
From this, my understanding is that if the variable is not set to 1, the MB1 watchdog might already be enabled by default—or at least it appears that way.
In this version, 36.4.3, I haven’t found explicit references to this variable. Is it possible that the watchdog is enabled by default during early boot stages?
Based on the traces I’ve shared, I have the following questions:
Do we need to explicitly set this variable to 1 to enable the WDT, or is it already enabled and setting it to 1 simply re-enables it?
Do you have any idea why this works when updating only a single partition, but not when updating the full image?
enable_wdt=1 is still the correct setting if you want MB1 to explicitly enable/program the watchdog.
The Re-Enabling WDT message suggests the watchdog may already have been enabled in an earlier boot stage, and MB1 is re-initializing it.
This is why enable_wdt=0 does not necessarily mean no watchdog activity is seen in MB1 logs.