Watchdog Configuration in MB1/MB2

Hello,

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.

Configuration:
misc {

debug {

    wdt_period_secs = <5>;

    wdt_enable = <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?

Thank you in advance for your help.

Hi lroca,

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.

Hi Kevin,

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:

Error: Return value 3                                         ] 013%
Command tegradevflash_v2 --pt flash.xml.bin --create --dev 2

I also tested different configurations of disable_wdt_globally (both 0 and 1), but the result remains the same.

Could you please advise if there is any additional configuration required or if this behavior is expected?

Thanks in advance.

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.

Hi Kevin,

I flashed the board with the default image, and afterward I updated the A_MB1_BCT partition with enable_wdt using the following command:

flash.sh -r -k A_MB1_BCT jetson-agx-orin-devkit mmcblk0p1

Is this the correct way to update a specific partition?

On the custom board, I noticed that the manufacturer has modified the setting:

cvb_eeprom_read_size = <0x0>;

Would this have any impact?

Thanks,

Yes, please use sudo for the flash script.

Do you have the EEPROM on your custom carrier board?
If not, please do that modification to prevent the reading during flash.

Hi Kevin,

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?

Thanks in advance.

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.

Both should work.