i.MX RT1064 watchdog (RTWDOG3) reset using LPO_CLK as clock source

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT1064 watchdog (RTWDOG3) reset using LPO_CLK as clock source

184 Views
johnpulera
Contributor II

Hello,

I am a little baffled by what I see here and am hoping the community might have some insight to offer. We've configured the RTWDOG to use LPO_CLK external (32.768KHz) oscillator as its clock source, and we observe the watchdog reset triggering at exactly the time we would expect (20msec) given the programmed timeout value (655) and clock prescaler (1) that we've selected. This expected behavior is observed under normal execution environment in which there is no problem with the 24MHz crystal; however, if we interfere with the 24MHz crystal input signal at XTALI, software execution and software's pinging of RTWDOG is interrupted as we'd expect, but a watchdog reset does not occur until 24MHz crystal signal is restored. In fact, the watchdog timeout countdown is effectively "paused" while the 24MHz crystal signal is disrupted. When 24MHz signal is restored, the watchdog reset occurs.

Once it's been configured, we would expect RTWDOG to reset the microcontroller regardless of bad 24MHz input signal since external 32.768KHz RTC oscillator clock source is selected. Is our expectation correct? Is 24MHz still needed to effect a watchdog reset even though the RTC clock is the chosen clock source?  

RTWDOG3-reset.png

FYI in the attached scope capture, the blip on CH1 where it is labeled "Watchdog Reset" is the GPIO channel reverting to the influence of the keeper pad configuration at moment of reset (vs being actively driven by GPIO peripheral). If we instead configure the pad with weak pull-down enabled, then we see CH1 transition to LOW at this moment if it was previously HIGH.

Thanks,

John P.

Labels (1)
0 Kudos
1 Reply

138 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @johnpulera,

The LPO_CLK is indeed independent from the 24MHz crystal input, but only on specific conditions.

See, "Table 57-3. WDOG Clocks" describes all of the clocks that are used by the WDOG modules. This table notes that the 32kHz clock for these modules will continue to run in low-power mode, and that the clock controller will synchronize this signal to the main clock (24MHz) during normal operation, while it will remain unsynchronized during low power mode.

EdwinHz_1-1711062201326.png

We can corroborate this on the Clock Controller Module (CCM) chapter, where the following is stated:

EdwinHz_2-1711062740220.png

Indeed, the 32kHz CKIL clock will be synchronized to the main 24MHz IPG_CLK when supplied to the requesting modules, in this case WDOG3. The following picture is from the "Table 14-4. System Clocks, Gating, and Override", which shows the clock roots for the WDOG3 module. BUS_CLK (wdog3_ipg_clk) comes from ipg_clk_root and LPO_CLK (wdog3_lpo_clk) from ckil_sync_clk_root:

EdwinHz_3-1711063009660.png

This synchronization is what prevents the 32kHz clock to be fully independent from the 24MHz clock and is most likely why you are seeing the interference shared between the two. This synchronization is done by design, to ensure a proper 32kHz signal at all times during normal operation. 

That said, following the logic of the aforementioned "14.6.1.1.1 CKIL synchronizing to IPG_CLK" section of the RM, in a low power mode (more specifically STOP mode), the syncing will not occur, and you should see no interference.

I hope this answers your question.

BR,
Edwin.

 

0 Kudos