Hi,
Let me put my question, in other way.
We have a hardware platform which is based on iMX35 platform. RTC chip is a on-chip.
Crystal clock source for RTC is derviced from a main clock source which is 24MHz. There is a divider factor(DIV750, which is hardware specific). So for clock source used for RTC is 32KHz(24MHZ/750 = 32KHz).
We have a RTC driver code, in this the configuration is done to use the 32KHz clock.
During RTC initialization, "OALRealTimeInit" function is getting invoked.
when the time is set in WinShell, "OEMSetRealTime" function is invoked, and each & every second "OEMGetRealTime" function is getting invoked.
The time is set in the device, which is same as Desktop machine time. We have added a retail message in the RTC "OEMGetRealTime" to check the time value update every second. We are seeing a drift in time after ~5-6 minutes.
I did a same test, by writing a sample application which continuously reads the time from RTC and display it on the console(Teraterm). With this also, there is a drift(Per hour, device time loosing by 90 sec compared to desktop machine time) is seen.
So, per sec device time loosing ~25msec.
But if 32.768KHz crystal is used, there will not be any issue.
See the below calculations:
(32768-32000)/(32000) = 768/32000 = 0.24
This value is exactly matching with above value(per sec device time loosing ~25msec)
But when I added a retail message, post RTC module reset (By setting SWR bit in RTCCTL register) and before setting the clock (configuring XTL bit, EN bit of RTCCTL registers). The drift is minimised drastically(Observed that per day, device time loosing by 1sec).
So, based on this test I understand that there is a settling time needed after RTC module reset. So that RTC registers get reset to default values.
I could not find the details any where, about how much delay needed.
So, please help me in this.
I referred MARPF2(iMX35 is the reference platform), RTC functionality is working fine here. Observed the changes are, there is a 32.768KHz crystal is used for RTC.