WinCE6.0 system time delay while updating minutes from rtc

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

WinCE6.0 system time delay while updating minutes from rtc

1,145 Views
santhoshreddy
Contributor I

Hi,

In Win6.0, iMX35 processor board , after the board is booted up. In WINShell time is not getting updated from RTC.

The device is set with a time which is same as desktop machine. But there is a drift seen.

After adding retail messages in RTC platform code, there is no issue seen.

I would like to understand why there is a delay needed. Please help me in this.

Regards,

Santhosh

Labels (1)
0 Kudos
2 Replies

472 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Take in Mind that RTC driver was develop for the i.MX35PDK board. The PDK board has an MCU. The MCU drivers is a stream interface driver that directly controls the hardware components provided by Freescale microcontroller unit MC9S08DZ60. The  MCU driver enables the 3-Stack board to provide the following software and hardware support:

• Supports the RTC function

• Supports GPIO extension

• Supports keypad scanning

• Supports touch screen control

• Supports power management

In case of RTC, the OAL RTC function use KernelIoControl to access the MCU driver to get RTC.We implement four basic

KernelIoControl for exchange RTC.

{ IOCTL_HAL_RTC_INIT, 0, OALIoCtlInitRTC },

{ IOCTL_HAL_RTC_QUERY, 0, OALIoCtlHalRtcQuery },

{ IOCTL_HAL_RTC_SYNC, 0, OALIoCtlHalRtcSync },

{ IOCTL_HAL_RTC_ALARM, 0, OALIoCtlHalRtcAlarm },

So, please  Use OAL RTC CEKT function to test the RTC function

Regards

0 Kudos

472 Views
santhoshreddy
Contributor I

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.

0 Kudos