Real-time clock (i.MX6 rtc-snvs) is very inaccurate.

Discussion in 'Troubleshooting' started by fetcher, Feb 9, 2015.

  1. fetcher

    fetcher Member

    Mar 9, 2014
    Likes Received:
    I've noticed the real-time clock (RTC), the one which can be kept running without main power by connecting a 3V battery to J1, is wildly inaccurate. While the system is running, the RTC on my main Udoo board (with coin cell fitted) gains roughly 35 minutes every hour(!) when compared to the NTP-synchronized Unix system clock.

    Here's an example, where I set the RTC to system time, verify both are in sync, then compare them again after one hour:

    # hwclock -w; date; hwclock; sleep 1h ; date; hwclock
    Mon Feb  9 09:51:48 EST 2015
    Mon Feb  9 09:51:49 2015  -0.624834 seconds
    Mon Feb  9 10:51:49 EST 2015
    Mon Feb  9 11:26:47 2015  -0.607533 seconds
    With main power removed (RTC operating from the coin battery), the clock runs too slow rather than too fast, though the inaccuracy isn't quite so awful then.

    Checking my friend's Udoo for comparision, that one's even worse, RTC running more than 6 times normal speed during power-on state:

    # hwclock -w; date; hwclock; sleep 1h; date; hwclock
    Mon Feb  9 06:11:44 EST 2015
    Mon 09 Feb 2015 06:11:45 AM EST  -0.110538 seconds
    Mon Feb  9 07:11:44 EST 2015
    Mon 09 Feb 2015 12:37:47 PM EST  -0.137387 seconds
    He doesn't have a battery connected, so it's kind of a moot issue, but I would have expected the RTC to nonetheless operate normally from main +3.3V power (Vdd_SNVS) while it is switched on.

    Does anyone care to repeat this test, or to guess at what might be going on? Did some or all production UDOO boards omit the 32.768kHz RTC crystal (X2 on page 4 of the schematic, connected to CPU pins RTC_XTALI, RTC-XTALO), forcing the i.MX6 to rely on its internal ring-oscillator?

    This might explain why trying to use the 32kHz clock for i.MX6-side PWM was giving me strange timing behavior...

Share This Page