Vybrid wdog a5 - premature timeout

[Luciano_Mougenot]

Issue:

• Seeing 7-15 second wdog-A5 timeout when configured for 60 seconds.

Configuration:

• With imx2_wdt.c's WDOG_WCR WT configured to 60 seconds (60*2-1 = idx 119 or 0x77)
• Confirmed with devmem, shows 0x7735 @ 0x4003E000

Reading:

• Reference Manual makes reference to the "low frequency reference clock" but does not:
  • Indicate it's source
  • If or how it can be configured
  • Whether or not the wdog A5 countdown can be read (ex: see it start from 60 s and count down to 0)
  • Appears to be an internal clock, with direction calculation of time for the countdown. (black box)

Observations:

• Time varies between LRUs (some 7, others 15 second watchdog timeouts) and sometimes units 'behave' and give 60 second count down (if observed long enough).
• watchdog daemon (watchdog_linux) takes /etc/watchdog.conf and:
  • divides the specified interval in half (ex: define 5 seconds, it will 'ping' every 2.5 seconds)
  • sends 7 'pings' for each interval, not just one.

Trouble shooting:

• Added prints to imx2_wdt.c to confirm WCR/WSR/etc.
  • WCR looks good, matches devmem etc.
  • WSR - too fast to see 0x5555 -> 0xAAAA transition by devmem, so we changed it to alternate (for debugging only), and then validated that the pattern was correct and that we only saw 0x5555 become 0xAAAA repeatedly with no other values/patterns in between etc.  So WCR's WT should be getting re-applied to the countdown (but timeout still in ~7-15s range for the majority of time-outs)

Work around:

• Set watchdog_linux conf interval to 5 seconds (aka 2.5 seconds) which then mitigates the watchdog premature time-out (not a preferred solution).

Questions:

• Has similar behavior been observed by NXP?
• Any thoughts/ideas on this issue?
• Is there a way to read/set how the "low frequency reference clock" is configured?
• Is there a way to read the countdown?
• Any ideas on what to probe/debug to see what could cause the "low frequency clock" to not calculate to real-world 'seconds' correctly?  Ex: 24Mhz clock is divided to derive the low frequency clock (not documented), and because of some jitter 'something' happens (already checked this clock and it looks clean per spec)?

Thanks

[AldoG]

Hello,

This may be cause by the VF6XX errata XTAL: In some cases the 24MHz oscillator start-up is slow
https://www.nxp.com/docs/en/errata/VFXXX_2N02G.pdf

e7128: XTAL: In some cases the 24MHz oscillator start-up is slow
Errata type: Errata
Description: In some cases the 24 MHz oscillator start-up is slow.
Workaround: A 2.2 MO resistor from XTAL to ground will make the startup times reasonable

Best regards,
Aldo.