IMX-93 Wdog interrupt clock source

[leoX]

What is the clock source for the wdog interrupt timing in IMX93? According to the RM, enabling the wdog interrupt provides 128 bus clock cycles for processing before a reset occurs. I understand that the bus clock frequency should be the selected 133MHz, which means there is less than 1 microsecond available.

However, when I toggle an IO pin in the interrupt and measure it with an oscilloscope, the actual interrupt duration is around 57 microseconds. So, which clock root is this timing derived from? By the way, I use the wdog1 for CM33.

[danielchen]

Hi Leo:

The clock source for WDOG1  in i.MX93 is  24Mhz oscillator (osc_24m), not the 133 MHz bus clock.

The 128 cycles mentioned in the reference manual are not based on the 133MHz bus clock.

You can check the actual clock rate using

cat /sys/kernel/debug/clk/clk_summary | grep wdog1

Regards

Daniel

[leoX]

Hi Daniel，

Thank you for your answering! I followed your method and confirmed that it is indeed a 24MHz clock. Based on the calculations, it should be around 5us, but the actual test result shows 58us. Therefore, I would like to know if this time can be adjusted to allow my interrupt execution time to be longer so that I can perform more recording tasks.

Best Regards.

[danielchen]

Hi Leo:

The watchdog interrupt grace period on the imx93 is derived from a 24Mhz clock, and the reference manual  specifies a 128-cycle window before reset.  However, the actual  interrupt duration you measured (~57us) includes software overhead, such as interrupt latency, context switching and GPIO toggling.

If you need more time before reset, you can implement a software timer that monitors system health and gives more time for recovery.

Or you can try whether you can use a slower clock source (external 32khz if available.)

Regards

Daniel

[leoX]

Hi Daniel，

I am toggling the IO port within the interrupt handler function and waiting for 5us each time, so this time (~57us) only accounts for the function execution time. Additionally, could you please explain in more detail the method to obtain more interrupt handling time before reset? Thank you a lot!

Best Regards.

[danielchen]

Hi @leoX 

you can use a software timer for pre-watchdog monitoring.

Instead of relying solely on the watchdog interrupt.

1 setup a periodic software timer (GPT or PIT) to monitor system health.

2 if a fault is detected, attempt recovery before the watchdog expires.

3 only let the watchdog expire if recovery fails. This gives you full control over timing and avoid the tight 128-cycle constraint.