AM3352: The system clock is inconsistent with the rtc clock read.

Hello, 

I jump in due to customer is inconvenient to access external network.

#1. Customer made a typo on the part number, it is PMIC TPS65910 , same as one of EVM's PMIC.

#2. Customer made a simple test code to read time by hwclock and date command as attached file:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char const *argv[])
{
	while(1)
	{
//		system("date -s '+1 day'");
		//system("date -s 23:58:30");
		system("date && hwclock");
		sleep(1);
	}
	
	return 0;
}

Tony,

Please help me make sure I understand the issue. Is it that the RTC and the system time are drifting apart over time? Over the run the two drift by about 10 secs?

This is the responsibility of the filesystem. In the SDK, we provide systemD that has a service to do this. Are they using the Arago filesystem? 

Basically, this is expected and there should be something in the system that synchronizes the two periodically.

This can be done with something like systemD or something like a cron job.

I hope this is helpful.

Ron，

Thank you. 
#1. Customer use SDK Arago filesystem. 
#2. Customer feedback the RTC clock is not accurate, as the system clock is accurate by comparing to host network clock. 
#3. TPS65910 RTC clock source has two option:external or 32KHz RC clock. Does below DTS configured the RTC clock source from external 32.768?

am33xx.dtsi 
		rtc: rtc@44e3e000 {
			compatible = "ti,am3352-rtc", "ti,da830-rtc";
			reg = <0x44e3e000 0x1000>;
			interrupts = <75
				      76>;
			ti,hwmods = "rtc";
			clocks = <&clkdiv32k_ick>;
			clock-names = "int-clk";
		};

am335x-evm.dts
&rtc {
	clocks = <&clk_32768_ck>, <&clkdiv32k_ick>;
	clock-names = "ext-clk", "int-clk";
};

#4. I let customer to check PMIC register DEVCTRL_REG(0x3F) bit 5 CK32K_CTRL to confirm the RTC clock source, but there is not I2Cx device under /dev on customer side, I can read PMIC register on my Linux environment on BBB:

on customer's board the command return error as below:

i2cget -f -y 0 0x2D 0x3F b
Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory

log has I2C registered already as below. Why there is not I2C device under /dev？

[    1.378418] tps65910-rtc tps65910-rtc: registered as rtc0
[    1.384352] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.391809] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[    1.398279] omap_hsmmc 48060000.mmc: Got CD GPIO
[    1.521971] input: volume_keys0 as /devices/platform/volume_keys0/input/input0
[    1.534084] tps65910-rtc tps65910-rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    1.547001] lis3_reg: disabling
[    1.550295] wlan-en-regulator: disabling


From the behavior of RTC clock is slower then system/netowork clock, I guess the PMIC RTC use the RC 32KHz other than 32.768 external clock, but don't know how to do it on customer's environment.

More questions:
#1. why no I2C device under /dev
#2. How to configure TPS65910 RTC use external clock in default. 
#2. Other thought about this issue?

Hi Tony,

I'm not sure about #1 above and i can't reproduce it. On my EVM, everything shows up correctly. The first thing I would recommend double checking would be the pinmux settings and compare those to the EVM via am335x-evm.dts. 

On #2, according to the bindings document for the PMIC, in /Documentation/devicetree/bindings/mfd/tps65910.txt, there is a "ti,en-ck32k-xtal" to enable the external crystal oscillator by default. There is also an example of how to add this.

I hope enabling the external crystal improves things. 

Keep in mind that most of this code originates with the desktop PC market.  So there are two clocks to consider:

1. The RTC clock on the motherboard (e.g. powered by coin cell or supercap).
2. The “system clock”.  This is the one you see when you run “time” or “date” commands.  It’s derived from the CPU clock and/or timers.

The “hwclock” utility allows you to use copy time from one of these clocks to the other.  So for example, on power-up you may want to take the time from the RTC clock and use it to set the approximate time of the system clock.  However, once the system is fully operational, there are things like NTP that get leveraged to more precisely set the system time.  So as a result, there may also be a desire to take the system time and copy to the RTC clock!

Take a look at the hwclock usage: 

Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE]

The “hc” stands for “hardware clock” (i.e. the RTC) while “sys” is the “system clock”.  So “hctosys” means hc -> sys.

In my opinion, you should not be expecting these clocks to remain perfectly aligned all the time.  However, if the drift is excessive you might need to look into some hardware adjustments (crystal capacitors, etc.) in order to reduce the drift.  The AM335x integrated RTC has some registers where you can calibrate the RTC, e.g. if you know how quickly it's drifting you can program some registers to counteract the drift.  I don't know if the PMIC has something similar.

Best regards,
Brad

Brad, Ron,

#1. The first thing I would like to confirm whether PMIC RTC clock source is configured rightly. but doesn't find I2C under /dev, so can't do that by using I2C to read PMIC register. and seems only I2C device not find, other devices are there. I don't know to how to figure out the driver issue.

#2. Customer measured the external RTC clock frequency of PMIC, it is precise, it should not result in so large drift in several minutes.

I agree with Ron's earlier suggestion of specifying ti,en-ck32k-xtal in the dts.  Given the severity of your inaccuracy, the most plausible explanation in my opinion is that the PMIC is configured to use the internal 32k clock rather than the external 32k clock.