i.MX ProcessorsのトピックRe: RTC clock forward

RTC clock forward

munoz0raul — Mon, 15 Jul 2013 11:22:14 GMT

Hello

I have a problem related to the RTC imx28.

When connecting a source in VBAT we have a consumption of 18mA when the power is off (operating system off), after that just this battery keeps the RTC board with this consumption.

After some time off and keeping VBAT powered by this source (4.2 V), we connect the equipment back to normal font and see the clock forward than it should be.

We are using the Yocto denzil to compile linux for the product, the default settings of kernel already linked items pertaining to RTC.

The kernel is the linux-imx-2.6.35.3-r24.

Have you seen any behavior like this?

Does it still lacks enable or configure anything on linux?

I am sending also. Config kernel.

Now appreciate the help.

Original Attachment has been moved to: config.zip

Re: RTC clock forward

CraigMcQueen — Wed, 09 Jul 2014 03:42:44 GMT

I have also seen an issue with both the Linux system time and the RTC running fast.

On an EVK running a Yocto build with Linux 2.6.35 kernel, with both system clock and RTC running off 24 MHz crystal, we've seen both clocks drift forwards by about 12 s per day. That's about 140 ppm error.

On our own hardware with a Linux 2.6.35 kernel (Timesys build, not Yocto), with system clock from 24 MHz crystal and RTC from 32.768 kHz crystal, the system clock drifts forward by about 12 s per day, while the hardware clock drifts forwards by about 14 s per day. That's about 140 and 160 ppm error.

Please see the attached logs and graphs. The logs were obtained by the attached script time.sh that obtained PC time from a Linux PC from the Daytime Protocol server on port 13. The graphs were obtained with the attached Python program.

Re: Re: RTC clock forward

CraigMcQueen — Thu, 10 Jul 2014 07:25:07 GMT

We have further results obtained when the EVK is configured to use the 32.768 kHz crystal for its RTC. I've improved my time logging method to decrease the granularity from 1 s to a smaller value. See the attached graph. It's showing a clock drift of about 66 s per day (about 760 ppm) for the RTC running on the 32.768 kHz crystal. It's showing a clock drift of about 11 s (about 125 ppm) for the system clock running on the 24 MHz crystal.

These drift rates seem well out of the spec for the crystals. What might be causing these high drift rates?

Re: RTC clock forward

jamesbone — Tue, 15 Jul 2014 19:42:19 GMT

We are discussing internally this issue, we will respond as soon as we have an answer.

Re: RTC clock forward

jamesbone — Wed, 30 Jul 2014 15:33:19 GMT

The load capacitors for 32k crystal have not been optimized on EVK.

The load capacitance of the crystal on EVK is 12.5pF. Ideally, we need to use 15pF load capacitors if we assume a stray capacitance of 5pF. Since we are using 10pF capacitors on EVK, the crystal would be running slightly faster than the nominal frequency.

On customer's design, they should use load capacitors that matches the crystal they are using.

Re: RTC clock forward

siddiquis — Thu, 19 Mar 2015 20:48:22 GMT

I am running imx28 processor on Technologic System's TS-7400-V2 hardware. Have linux kernel 2.6.35.3 on it. I have about 14sec of drift per day in the system time. But the RTC more or less remains accurate over a day if I am not syncing my RTC from system time or vice versa. In other words if I leave them running independently, the system time moves forward. But the RTC doesn't. Wondering if you are doing a sync from system to RTC as a cron job of some sort.

Another funny thing to notice, if I run ntpdate back to back, it keeps making adjustments in the order of 0.6-1sec every time I run it. Seems like I can never have an accuracy of < 0.5s in system time. Does not make sense. This could only mean the ntp client is not properly working on this system. On a different linux base hardware the ntpdate works just fine, and makes adjustments in the order of 0.03-0.05seconds in six hours interval, which is normal.