Hello,

I have a design based on sam9263 and wince6.0, I see a problem regarding the time precision of the date and time applet: During the normal operation the RTC seems to run faster (gain 5 seconds in an hour), during the suspend mode is almost percise.
I have check the esternal oscillator and it's 32.768 KHz as should be. I quess the the rtc implementation in low level driver using RTT should be a consolidated part of the BSP....

Somebody has already face this kind of problem?

do you use "4 pin standard crystal"?

here the specs:
"MC-306 32.768kHz" 8x4mm
Quarz smd F=32768Hz +/-20ppm, Tc=-160ppm, Cl=12.5pF,
8.7x3.4mm, Ta=-40..+85°C manufacturer:Epson

thanks

Hello,


Anyone has this problem or is only my one?

Is your RTT time/date enough precise? For what I can see in one day there is adrift of several seconds (more than 60) ....
For me is important to understand that this precision is right or maybe there is something else....
thanks

Hello Adeneo,

I would like to ask you if you have already notice this behaviour in your system or is something realted to my HW/environment. I'm using your BSP for at9263 wince 6.0 r2 and the RTC driver is using the RTT timer (external 32Khz and it's quite good).
The precision is affected also by the fact that the system is in suspend mode or running normally.

please, can you give me some feedback on that?
thanks
bob

Hello Bob,

I've got a similar problem with the RTC.
The SAM9263 runs under linux 2.6.30.
The crystal is an citizen
CM200S32.768KDZF-UT
Frequency Tolerance +-20ppm
Cl 12,5pF
Some boards run fine,
one cpu is 6 min. per hour too fast,
some are just a little faster, e.g. several minutes a day.
The signal waveform measured at the crystal pins looks good.
No difference between good and bad CPUs.
Also the application engineer at our distributor has not heard of this problem before.
Maybe a year after the original post, anyone with new findings?

Regards,
Karlous

I think the original WinCE problem stems from the fact it doesn't read the actual RTC again after it boots, it uses an internally ticker interrupt to mark time using the system clock, not the 32.768 KHz. It resyncs when it reboots next.

What's driving your primary clock, some generic crystal, or a TCXO with some reasonable ppm rating? Have you actually calibrated it with a frequency meter a couple of orders more accurate than the level of accuracy you desire?

Calibrate your clocks, and be aware that quartz oscillators age, and are effected by temperature, voltage, etc.

A good comparative source would be a local NTP server, or GPS 1PPS.