MOD54415 RTC Accuracy

[gavinm]

Conclusions
- The RTC on the processor of the 54415 is a very useful addition that effectively comes at just the additional cost of a battery (re-chargeable or standard) and resistor.
- The 2kB battery backed RAM is also a useful addition for often changed parameters (eg machine cycle counters for Pass / Fail etc), that are best not saved in flash memory.
- Over a sample of 3 modules (all bought at the same time June 2014), the default accuracy of the RTC was found to be about 38ppm. The RTC all lost time ie their time was behind real time. (by 14 seconds over 4.25 days)
- This equates to about 1 min 40 sec per month or about 10 minutes per 6 months (when Day light saving time correction would have to be manually performed anyway so the clock could be corrected at this time).
- This might be adequate for many applications.
- The RTC can be compensated by applying a correction INTERVAL and VALUE (see Freescale manual section 37 and all the notes above!)
- Watch out! the Freescale description of the compensation mechanism is quite ambiguous and can be misleading.
- For simple compensation, once the required compensation INTERVAL and VALUE have been calculated (by observing the RTC operation over a significant time period compared with an accurate time source), they can be written to the RTC compensation register and compensation will continue without any further software support necessary.
- To make the RTC run faster use a negative correction VALUE. To run slower, use a positive correction VALUE.
- The correction is applied to the first second in a compensation INTERVAL that can be set between 1 to 255 seconds (0 disables compensation - which is the condition on first power on). In combination with the correction value this gives very fine control over compensation that can be applied.
- If a backup battery is connected to V Standby, the INTERVAL and VALUE data is retained and the compensation continues during battery backup operation. (So technically the compensation register does not need to be written on every power on reset - but it will do no harm to write the required compensation values on power on).
- Of course the RTC will vary with crystal temperature. If really fine precision is required you could use a look up table or calculate the temperature compensation needed assuming you are measuring the board temperature. Crystal frequency tolerance is +-20ppm and temperature coefficient is -0.034ppm/degC.
- Compensation for both crystal frequency and temperature (if necessary) must be combined into the one set of compensation INTERVAL and VALUE figures.
- If it is important to your application that every individual elapsed second of the RTC is identical then you will need to compensate every second (INTERVAL = 1) and choose a VALUE accordingly. This will undoubtedly result in worse long term accuracy. It's a compromise.
- Finally from my testing with 3 MOD54415 boards the compensation data to correct for 14 seconds error in 4.25 days is INTERVAL =4 seconds, VALUE = -5 counts. Theoretically this will correct for 14.007 seconds over 4.25 days leaving an error of only 0.007 seconds (or 0.3 seconds in 6 months).

I hope you find this useful ...

[gavinm]

Hi Roland,

Yes - I'll add the one line of code to set the compensation data on my 3 units before the weekend. They will be switched off for most of the weekend (I and others might have to be working on the rest of the machine some of the time), and see how it performs and report back next week.

[roland.ames]

per 6 months (when Day light saving time correction would have to be manually performed anyway so the clock could be corrected at this time).

The RTC is capable of adjusting for DST automatically. see RTC_CR[DST_EN] (in 37.4.9) and RTC_DST_??? (in 37.4.15, 37.4.16, 37.4.17). However, I am not sure that its functionality is useful. I know for example that some regions switch in and out of DST on the nth sunday of a month, rather than on a particular date, and the RTC doesn't seem to be able to handle that.

[gavinm]

Yes, while writing that note I wondered how long it would be before auto Day Light Saving Time changeover was raised!

You're absolutely correct in the reason why I've ignored it. Here in Britain we don't change on specific dates, it's always in the early hours of a Sunday morning (1am to 2am, or 2am to 1am), towards the end of March and October. It might be more appropriate for other regions, but I have no idea what the "rules" are anywhere else.
So as far as I can see, even if you were to use the DST switching functionality, you would still have to access the device to change the changeover dates at least annually, if not 6 monthly.

Of course all this is based on the assumption that we are talking about NB systems that are NOT connected to the internet. They are on a small very local sub-net (possibly restricted to just inside a machine or machine cell), with no access to Time Servers or other usual network resources.

Just had a quick search on Google and I couldn't find anywhere that uses fixed dates. Various different Sundays (or one occasion of 11pm on a Saturday night), was all I could find. So to make this work automatically (like on a PC) I assume the device uses it's internet connection to update the auto switch over date, or simply uses the connection to a time server to keep the time correct.
But like I say, my interest is for those situations where the NB is operating without an internet connection.

[ecasey]

For DST would it not be better to set the RTC to GMT and use an environmental variable to manage regional time and DST?

When setting the time from the internet, I use this construct:

Code: Select all

putenv("TZ=EST5EDT,M3.2.0/2,M11.1.0/2"); /* Set the time zone to Eastern Standard Time (EST+5),   */

and then just use localtime() to display the time, something like this:

Code: Select all

void WhatTime(int sock, const char *url) {
	time_t t = time(NULL);
	struct tm *Time = localtime(&t);
	strftime(buffer, 80, "%B %d, %Y at %H:%M ", Time);
	writestring(sock, buffer);
}

In the time zone (TZ) environment string the "M3.2.0/2" and "M11.1.0/2" bracket the DST between second Sunday of March at 2:00 am and the first Sunday of November at 2:00 which is the EST convention.

Ed

[dciliske]

Wonderful research Gavin. I'll agree with you about Freescale's manual being convoluted or wrong. That said, it's still a lot better than some of the other vendors.

Your investigation is one of the things that makes this forum a great place to visit.

-Dan

[gavinm]

Thanks Dan.


Ed - I'd say you are absolutely correct when you say :

set the RTC to GMT and use an environmental variable to manage regional time and DST?

Thanks for the code examples. For me in the UK the TZ variable is: (5th occurrence means the last Sunday in March and October, and BST is British Summer Time):

Code: Select all

TZ="GMT0BST,M3.5.0/1,M10.5.0/2"

[gavinm]

Test Results.

So to re-cap, 3 different MOD54415s with no RTC compensation the RTC accuracy over an elapsed time of 4.25 days with the power turned off (so RTC working off 3v battery backup power):
Mod 1 = 14 sec slow, Mod 2 = 14 sec slow, Mod 3 = 12 sec slow

Calculated the theoretical compensation needed (ignoring temperature effects) and added this line to the MCF541X_RTCSetTime RTC time setting function:

Code: Select all

sim2.rtc.compen = 0x04FB; //Compensation interval 4s value -5 (0xFB)

Set the RTC to my PC time and monitored the time again ...

Over an elapsed time of 4 days with the power turned off for 3 days (so RTC working off 3v battery backup power) and on for about 8 hours of the last day:
Mod 1 = 2 sec fast, Mod 2 = 2 sec fast, Mod 3 = 1 sec fast.

Much better, around 14 seconds per month, just over a minute per 6 months. Bear in mind that temperature effects (that I am not measuring or compensating for) will make this vary, so it's only approximate.

So this shows that the compensation does continue to operate without any other software intervention every compensation interval, and that my calculation of the compensation data is broadly about right.

One question to be addressed is just how often do you need to update the system time from the RTC time ... At the present I just read the RTC (which is set to GMT) and set the system time on power on, then use the system time - with appropriate localisation for daylight saving and local time (which here in UK is zero at the moment!).
But of course having spent all this time getting the RTC accuracy better, I think I need an algorithm to use it to update the system time more often as I think the system time drifts off quite quickly. This would not be too much of a surprise as I assume it will be derived from the processor clock.
So maybe I'll use an algorithm that updates the system time from the RTC (basically a call to MCF541X_RTCSetSystemFromRTCTime ) something like every hour (or maybe more often ...)

[gavinm]

Some information about the System Time.

My 3 separate MOD54415 systems were left powered on for 10 hours and the system time change recorded.
On power on the system time was set from the RTC which had just been set to my PC time (which is connected to an NTP server).
After 10 hours the system time was in error by the following amounts:
Device 1: 13s fast, Device 2: 14s fast, Device 3: 17s fast. All relative to the time at the start of the 10 hours.

By "fast" I mean they had gained time, so if the real time was 17:00:00, Device 1 was reading 17:00:13.

So I'd conclude that depending on how accurate you want the use of the real Date / Time in your application it you either need to update the system time from the RTC pretty often, or maybe always "get" the RTC time when you use a time stamp. From this sample of 3 modules the system time is in error by more than 1 minute per 2 days.

[joepasquariello]

Gavin,

I was looking for info on the MOD54415 RTC and found this thread. Thanks, it's very helpful.

Regarding system time, in addition to whatever error you might have due to do variation in crystal frequency, the NNDK at the time of your testing had an issue that caused system TICK periods to be slightly incorrect. The size of the error was a function of both the prescaler and modulus values for the PIT. In tests with 5213 and 5234, I found that the error could be large enough to cause system_time to drift at at a rate similar to what you measured. If you're still interested, and you're now using NNDK 2.7.0 or greater, you might repeat your tests of system time.

For the test, set TICKS_PER_SECOND to 125. That's the smallest value (I think) which results in selection of prescaler and modulus values that divide evenly into CPU_CLOCK/2. With the default value of 20, you get prescaler=7 and modulus=48828.125. With 125, you get prescaler=4 and modulus=62499 (exactly), so system time drift should be a function only of deviation of the actual clock frequency from the nominal 250 MHz.

Joe