caching of the real-time clock value

Hi,

I am observing problems with the consistency of calls to
System.currentTimeMillis().  It appears that reads to the real time clock
chip are getting cached and System.currentTimeMillis is incremented based on
the OS tick.  This results in time progressing incorrectly when compared to
an external (non-TINI board) source.  On a periodic basis (every 10 mins) it
looks like the real-time clock gets read and System.currentTimeMillis jumps
to the current(RTC) time.  I've been observing this problem in a number of
ways, but the easiest is with a simple test loop such as:

long stop = System.currentTimeMillis() + 50 * 60 * 1000;    // run for 50
minutes
long last = System.currentTimeMillis();
for( long time = System.currentTimeMillis(); time < stop; time =
System.currentTimeMillis())
{
    out.print("time: ");
    out.print(time);
    out.print("  diff: ");
    out.println(time - last);
    last = time;
    try { Thread.sleep(1000); } catch (Exception ie) {}
}

I stuck this inside a slush command and logged the results through a telnet
session.  In most cases the diff time is 1060+-3 ms.  About every 10 mins
(565 print lines) the diff time will be 1200+.  Based on other tests I
believe this is because at that time the System.currentTimeMillis() call
resets to the actual RTC value.

Can anyone confirm the reasons for this 10 minute reset/anomaly I'm seeing
in time reading?  Is there a way to always read from the RTC?  If I used the
System_GetRTCRegisters native api function will it return the raw RTC value,
or is it being cached also?

Thanks,
-Aaron

______________________________
Aaron Buchanan
Firmware/Software Engineer
_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini