Verdin iMX8M Plus RTC Inaccuracy

atrester · April 8, 2025, 10:30pm

Verdin iMX8M Plus Quad 4GB WB IT V1.1B

Howdy,
Our team is seeing concerning behavior regarding the on-board RTC module. Primarily, we’re experiencing much much larger-than-expected time drift.
We’ve had at least 10 units deployed now and have seen this behavior on all of them. The clock drift is noticeable, falling behind by anywhere between one and ten seconds every ten minutes that we check.

We’re not doing anything out of the ordinary. We set the time and expect the RTC to maintain within seconds per day so long as it remains powered.
Is there some sort of calibration that we need to perform before being able to reference the clock? Anything else fundamental that we’re forgetting? I’ve reviewed the Epson RX8130CE application manual and nothing in particular stands out to me.

Thanks in advance,
Alan

ToradexAI · April 8, 2025, 10:31pm

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello there!

The Verdin iMX8M Plus module is equipped with the Epson RX8130CE real-time clock (RTC). This RTC operates using a 32.768-kHz crystal oscillator and offers features such as a user-programmable free-running counter, a resolution of one second, and a trimmer register for generating a precise 1-Hz clock.

The drift you are experiencing, where the clock loses 1-10 seconds every 10 minutes, is indeed unusual for this RTC. While I can’t provide specific calibration steps without more detailed information, I can offer some general advice on troubleshooting RTC issues:

Check Software Configuration: Ensure that your system’s software is correctly configured to interface with the RTC. This includes verifying that the correct drivers are loaded and that the system time is being synchronized with the RTC.
NTP Synchronization: Consider using Network Time Protocol (NTP) to regularly synchronize your system clock with an external time server. This can help mitigate drift issues by periodically correcting the system time.
Review System Logs: Examine system logs for any errors or warnings related to the RTC. This might provide clues if there are software-related issues affecting the RTC’s performance.
Firmware Updates: Ensure that your system is running the latest firmware and software updates, as these can include important fixes and improvements for RTC functionality.

If you have further questions or need more detailed guidance, feel free to ask!

Best regards,
Toradex AI Assistant.

benjamin.tx · April 9, 2025, 8:22am

Hi @atrester , what is the OS on your Verdin iMX8MP? How do you find the drift? Does it occur after a reboot or while Linux is running without a restart? And is the NTP enabled or not?

atrester · April 9, 2025, 3:18pm

Our OS is Linux-Yocto. @hedry is part of our SW team and can provide specific details.

We’re able to capture the drift by manually updating the date/time (synced to one of our PCs). We can check the reported date/time on the SoM some minutes later and already see the drift I mention above. This occurs regardless of whether the system is rebooted or is left running. (VCC_Backup is always powered from our battery).

NTP is not enabled.

Also wanted to add, because I didn’t specify in my original post: we are only ever seeing drift in the negative direction (losing time).

atrester · April 9, 2025, 10:21pm

I’ve played around with our systems some more and discovered new, helpful, information:

Looking closer, it does not appear that the RTC clocks are drifting or lagging behind after all. Rather, when the SoM is powered-ON and the RTC is set, it is maintaining that date/time accurately.

The RTC stops counting time as soon as the SoM is turned-OFF (via CTRL_PWR_BTN_MICO#) and only begins counting time again when the SoM is turned back ON. Because we routinely, quickly, power-cycle the SoM, this presented itself as a gradual drift. The time doesn’t reset - it simply picks up where it left off.

Our system is battery powered, meaning that the 3.3V (VCC) rail is always powered. We rely on the PWR_BTN interface to turn the SoM ON/OFF. The VCC_BACKUP pin (249) is connected to the same 3.3V rail. So, VCC_BACKUP remains powered even when the SoM is turned OFF.

This behavior is distinct from when we remove power from the system altogether (by disconnecting the system battery). In that scenario, after being unpowered for >10sec, the RTC returns a default date/time value when referenced again.

How do we keep the RTC counting even when the SoM is turned OFF?

benjamin.tx · April 10, 2025, 9:31am

Hi @atrester ,

As long as the RTC on the module is powered, it should keep counting. Please do the following test so we can have more information.
First, issue timedatectl , and record the RTC time.

root@verdin-imx8mp-07331018:~# timedatectl 
               Local time: Thu 2025-04-10 09:20:13 UTC
           Universal time: Thu 2025-04-10 09:20:13 UTC
                 RTC time: Thu 2025-04-10 09:20:13
                Time zone: Universal (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Then, power off the module via CTRL_PWR_BTN_MICO# ,and measure the voltage on VCC_BACKUP pin (249). Wait for a minute.

Turn on the module again, and issue dmesg|grep ds1307 .

root@verdin-imx8mp-07331018:~# dmesg|grep ds1307
[    1.814629] rtc-ds1307 0-0032: registered as rtc0
[    1.820482] rtc-ds1307 0-0032: setting system clock to 2025-04-10T09:20:56 UTC (1744276856)

Kernel will read the time from the external RTC and set the system time to it. In my test, system time is set to 2025-04-10T09:20:56. Before powering off, the RTC time was 2025-04-10 09:20:13. So the RTC keeps counting when the module is turned off. Let’s see what happens on your module.

By the way, may I ask which region you’re from? My colleagues nearby can assist you more promptly.

atrester · April 10, 2025, 5:03pm

Hello. We’re located in North Carolina, USA.

I monitored VCC_BACKUP during our power cycles and found that it remains at a constant 3.3V at all times.
I tried to follow your steps and think that I’m onto something! After booting up the system from a hard shutdown (Removing VCC & VCC_Backup), and using our utility to set time this is what I get:

root@verdin-imx8mp-ppu:~# timedatectl
Failed to query server: Failed to read RTC: Invalid argument

However, system time is reporting correctly:

root@verdin-imx8mp-ppu:~# date
Thu Apr 10 12:56:42 UTC 2025

Once I’ve manually synced time, things work better

root@verdin-imx8mp-ppu:~# hwclock -w
root@verdin-imx8mp-ppu:~# timedatectl
               Local time: Thu 2025-04-10 13:00:02 UTC
           Universal time: Thu 2025-04-10 13:00:02 UTC
                 RTC time: Thu 2025-04-10 13:00:02
                Time zone: UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Also, after doing this, turning the SoM ON/OFF does not result in lost system time!
So, it seems to me that we’re missing a fundamental step to properly disable NTP and sync the system time with the RTC.

Can you share what the recommended sequence of events should be (at boot, at shutdown, and periodically when running) to correctly set time?

Thanks,
Alan

benjamin.tx · April 11, 2025, 12:15am

Failed to query server: Failed to read RTC: Invalid argument

This means there is not a valid time counted in RTC. And the RTC needs to be rewritten. The RTC will be automatically written when system time is syncd from a NTP server. Otherwise, you have to manually set the RTC by hwclock -w as you did.