i.MX93 RTC XTALI Duty Cycle

[rfgemat]

Hi,

We are planning to use the internal 32 kHz RC oscillator of the PCA9451A to drive the RTC_XTALI input of the i.MX93. We are aware that the frequency of this output is neither highly accurate nor stable; however, we do not intend to use it as a precise time reference within the i.MX93.

Our concern is related to the duty cycle specification of the i.MX93. The input clock requires a duty cycle within a tolerance of 45% to 55%, whereas the PCA9451A specifies a wider range of 30% to 70%.

Do you see any functional risk in using this clock source under these conditions?

Best regards,

Raphael

FRDM-i.MX93 i.MX93 

[yipingwang]

Yes — there is a functional risk, but it is usually low in practice if the signal quality is otherwise clean. The risk is mainly related to input buffer behavior and RTC reliability (especially startup and low‑power modes) rather than steady-state operation.

Real risk analysis

Case 1 — Normal digital clocking (most likely OK)

If:

• Signal is CMOS-level clean (fast edges, no distortion)
• Frequency ~32 kHz (very low)
• No XTAL mode is enabled internally

Then:

• RTC logic mostly triggers on edges
• Wide duty cycle (30–70%) still gives sufficient high/low pulse width (~9–21 µs)

Conclusion:
No functional failure expected in most silicon — low risk

Case 2 — Borderline or worst-case conditions (risk exists)

Risk increases if:

(A) Input buffer threshold + asymmetry interaction

• If duty cycle skews (e.g., 30/70 + slow edges)
• One phase becomes marginal near VIH/VIL region

→ Can cause:

• double-trigger
• missing edges
• internal metastability (rare but possible)

(B) Very low-power / SNVS / RTC domain

• RTC domain may use ultra-low power clock conditioning
• Internal filtering or stretch logic may assume near-50% duty

→ Risk:

• clock rejection or distortion
• unstable RTC increment

(C) If XTAL mode is accidentally used

If the pin is configured expecting a crystal:

→ The 30–70% waveform can:

• disturb internal Pierce oscillator biasing
• prevent startup or oscillation

This is a real failure mode

Case 3 — Spec compliance / production variability

This is the most important practical risk:

• i.MX93 datasheet explicitly requires 45–55%
• PCA9451A guarantees 30–70%

 Therefore:

• You are operating outside the guaranteed spec
• Behavior is not formally guaranteed across PVT (process/voltage/temp)

4. Quantitative sanity check

At 32 kHz:

• Period = 31.25 µs

Duty cycle extremes:

Case	High time	Low time
50%	15.6 µs	15.6 µs
30%	9.4 µs	21.9 µs
70%	21.9 µs	9.4 µs

Even worst-case:

• pulses are still very long (>> internal setup times)

This is why it usually works in practice

5. Practical recommendation

Acceptable if:

• RTC is not used for accurate timing
• System does not rely on precise wake-up timing
• You accept non-guaranteed behavior