MOD54415 RTC Accuracy

[gavinm]

This is a branch of post http://forum.embeddedethernet.com/viewt ... f=5&t=2095 MOD54415 RTC Month Error. I've started a new post as this is information about accuracy and use of the internal compensation logic, not the errors in the NB firmware for setting the month.

In the other post I noted that the RTC was not very accurate, but I'd try and check this out ...

As I said before not very accurate - but I'm interested in seeing how good the compensation register might make it. I've studied the Freescale manual and I think I've got it sorted in my mind. You can set correction time interval of between 1 and 255 seconds and then once per this time interval a correction value (-128 to +127) that will be used to adjust the 32768 divider that gives the 1 Hz clock. The trouble is you'd have to monitor the RTC over a significant length of time and compare against an accurate clock to judge how much to compensate by. Then hope that all the crystals in a batch of modules are similar enough to apply the same correction! But interesting.

So I've now conducted a test with 3 different MOD54415s. They were in their default RTC state ie no RTC correction / compensation was applied.
Using my PC as the reference time base for this test (it connects to a time server periodically, and it's the best reference that I have easy access to), all 3 modules internal RTC were set to the correct time on Friday 14th Nov at 1pm.
The power was then switched off (so the RTC has been running on the 3v lithium rechargeable battery).
They were powered up (system time is set from the RTC on power on) and the time checked at 7pm 18th Nov. Elapsed time 4 days 6 hours = 102 hours or 367200 seconds.
Results were MOD1 14 seconds slow, MOD2 14 seconds slow, MOD3 12 seconds slow (slow means the RTC time was behind the real time on my PC).
Promising that they were all so similar. All 3 were bought at the same time and thus the expectation should be that the 32kHz crystals were all from the same manufacturing batch.

The first thing to say is that this was not as bad as I thought it might be, but it is still an error of 38.13 ppm. This is an error of 102 seconds (1 min 42 secs) in a 31 day month. Or put another way, if this was used as a RTC in an instrument where the time / date was only corrected once every 6 months (when daylight saving changed), the time would be about 10 minutes in error and could be corrected at that time. So for many applications that might be good enough?

It's probably important to say that this is the result of one test at one point in time and two possibly significant factors might have a bearing on the results...
1. The modules were on a machine in an industrial factory environment over a weekend in Britain in November when the factory would be mostly unoccupied. Although the weather has been unseasonably mild, it would have been cold through the night, and warmer through the day. Crystals are temperature sensitive devices, so this might influence the results.
2. The power was off so the RTC was operating on 3v battery. If the power was on (3.3v) this might influence the results.

Having noted those points (and now ignoring them!), what about correcting the RTC error using the on board RTC compensation ...
WARNING - the next discussion is theoretical (at the present), based on my understanding of the operation of the RTC compensation from reading the Freescale 54415 reference manual (section 37, particularly 37.4.18 and 37.6.1). I have not tested this (yet) and will report back to this post if I get round to trying it.
Having said that the following is my understanding of what would be required to correct for the 14 seconds in 367200 seconds error.

The RTC has an up counter counting the 32kHz crystal oscillations. When this counter reaches the terminal value this 1 Hz signal is used to increment all other date / time registers.
My understanding is that the compensation works by correcting the 32767 up counter with a pre-loaded VALUE (-128 to +127). This is done every INTERVAL (0 to 255) seconds. INTERVAL and VALUE are the numbers required to be loaded into the RTC Compensation Register (RTC_COMPEN) address 0xFC0A_8028 or sim2.rtc.compen in Netburner speak.
This is a 16 bit (word) register. The least sig byte is the compensation VALUE, the most sig byte is the compensation INTERVAL and the register is reset to all zeros on power on reset. An INTERVAL of zero disables compensation, so this is the default state. As far as I can see the NB RTC set and get functions do not change the compensation register.

In a really ideal world, you'd want to apply the compensation every seconds so that each second was of identical duration. But this would only give you a 1 in 32768 resolution of correction, ie steps of about 30ppm.
From my measured data above I need to correct for 14 seconds in 367200 seconds (about 38.13 ppm).
Put another way, each 1 seconds the 32kHz up counter needs to be corrected by 32768 * (14 / 367200) = 1.249 ticks. Obviously you can only "adjust" this counter in integers, so by simple iteration every 4 seconds the count needs adjusting by 1.249 * 4 = 4.996 counts. This is pretty close (close enough for me - remember other factors like temperature variation will probably have a bigger effect than the error in this compensation). The RTC on my modules were slow, so I assume to speed them up I need to preload a positive number as the compensation VALUE so that seconds will be faster to reach the terminal count and cause a second increment.
So my theoretical calculations suggest that if I use an INTERVAL of 4 and a VALUE of +5 I will compensate for the 14 in 367200 error.
As a quick check 5 counts in 4 times 32768 counts is 5 / 131072 ie 38.1470ppm and we were aiming for 38.1264ppm - good enough.

Applying this correction to my original error of 14 seconds in 367200 seconds.
In 367200 seconds there are 367200 / 4 = 91800 correction INTERVALs. Each of these corrects by 5 counts of the 32kHz counter, so 5 * 91800 = 459000 counts.
This represents a correction over the 367200 seconds of 459000 / 32768 = 14.0076 seconds. Close enough for me!

If I get around to trying this I will add some feedback to this topic.
There is a potential complication, and the Freescale manual does contradict itself about the repetative nature of the compensation.
In section 37.4.18 Table 37.21 it says that the INTERVAL register is cleared at the end of each compensation cycle when a bit in the status register (CDON) is set

Field1 Description
15–8
INTERVAL
Compensation interval. Indicates the window in seconds when the compensation must be carried out. A bon-zero
value starts the compensation logic. This register is cleared when RTC_SR[CDON] is set.
0x00 Compensation logic disabled
0x01 1 second
...
0xFF 255 seconds

If this were to be the case, you would need software to continually check the CDON bit and reload the INTERVAL and VALUE data into the compensation register for compensation to be continuous.
This seems to me to contradict the notes in section 37.6.1.2 that say...

If no new value is programmed, the state machine continues to perform compensation with the previously programmed values until compensation is disabled by writing zero to the compensation interval.

and ...

When the compensation interval completes, the RTC_SR[CDON] bit is set and if compensation is still enabled, the next compensation cycle starts

I hope that at the end of a compensation interval (every 4 seconds in my case), the compensation register is left unchanged an the compensation continues to operate until changed or disabled.

This whole procedure is of course not very practical for volume manufacture as it requires individual (or maybe batch?) testing to calculate the compensation required and then individually applying to each NB module. If it were possible access to an Time server would be much preferable. But for those occasions where this is not possible, it suggests that by individual tuning you can achieve very acceptable accuracy.

I hope this is of some interest ...

[roland.ames]

Thanks for being so generous with your work.

My reading of the manual suggests to me that you will need to reenable the compensation every interval. This may be as simple as just resetting the CDON bit by writing a one to it. (or reading the register??)

in 37.4.10

The compensation done bit is
cleared on reads.

but I think this wrong and the bit is cleared by writing a one to it ??

in table 37-13

Compensation done. Read-only bit that is cleared when one is written to it.
0 Compensation busy or not enabled
1 Compensation complete
Note: This bit is set a few oscillator cycles before the actual compensation interval completes, so that back-to-back
compensation can be enabled.

my copy of the manual (MCF54418RM Rev. 4 January 2012) has a different 37.6.1.1

The operation starts in an idle state waiting for the firmware to enable compensation. Since the same
hardware logic is used for temperature and crystal compensation, the firmware provides a value that
accounts for correction for both temperature and crystal. When enabled, the compensation cycles are
added or removed until the compensation interval expires. When the compensation interval completes, the
RTC_SR[CDON] bit is set and if compensation is still enabled, the next compensation cycle starts. The
compensation state machine returns to the idle state when you clear the compensation interval. A newly
programmed value is picked only when the current compensation cycle has completed.
Figure below shows the flow chart for the logical compensation flow of the state machine which has been
explained in subsequent pages.

I found the wording of the manual confusing to say the least.

It may be worth contacting Freescale for clarification.

[gavinm]

Hi Roland,

You said...

My reading of the manual suggests to me that you will need to reenable the compensation every interval. This may be as simple as just resetting the CDON bit by writing a one to it. (or reading the register??)

From reading the manual, I tend to agree, as in Table 37.21 it clearly says

This register is cleared when RTC_SR[CDON] is set.

And as CDON is set at the end of each compensation cycle, it follows that the register will be cleared setting the INTERVAL to 0 and thus disabling compensation.

However, just above this in section 37.4.18 it does say

The RTC continues to compensate with this value until it is disabled by clearing the INTERVAL bit. When
programmed a new value, it takes affect when the current compensation cycle completes.

... which sounds more promising - although there is not an INTERVAL bit, there are 8 INTERVAL bits making the 0 to 255 seconds interval byte ...

Common sense also tells me that it would only be sensible to continue compensating forever once an INTERVAL and VALUE were set. What would be the point of adjusting the RTC counter only once in a cycle and then never again (so 1 seconds increment is corrected but no other second increments were corrected??)

In practice only experimenting and trying this will reveal the answer.

You said

my copy of the manual (MCF54418RM Rev. 4 January 2012) has a different 37.6.1.1

...err actually no, my version of the manual is identical, the sentance I was quoting came from a little lower down the document in 37.6.1.2 "Compensation Logic Hardware" - sorry! I'll see if I can edit it.

[gavinm]

Hmmm - if I can only just find the time to test this out and report back, this is not far off being an Application Note!

[roland.ames]

It seems this can only be resolved with tests.

the following is guesswork:

It seems like there are two different uses envisioned:

1) every now and again, check how wrong the clock is and adjust it by some fixed delta to correct it. This is compensation rather than calibration. it has advantages over just setting the correct time, as it guarantees a monotonic clock.

2) calculate the error and setup the code so that the compensation is running continuously. This is calibration, and is essentially what you are trying to achieve. described in 37.6.1.3 ?? described as back-to-back compensation in table 37-13. this requires monitoring the CDON bit and then when it is set, [load a new compen value,] then clear it by writing 1 to it.

[gavinm]

Yes I agree. And yes point 2 is what I'd like (although in practise I can probably live with the 10 minutes per 6 months that I appear to have with zero compensation!)

I'm still 50/50 whether the software that you describe will be needed - I think there's a chance that once loaded it will continue to compensate (or is this just hope?)

this requires monitoring the CDON bit and then when it is set, [load a new compen value,] then clear it by writing 1 to it

If I get the chance to test I'll report back ... but probably not this week.

[gavinm]

Wait!! I think we're both being stupid and missing an obvious point ....

The RTC continues to work with the power off on battery (or super cap for a few hours at least!) backup. During this time there can be no "software" maintaining the correct compensation operation by re-loading the INTERVAL and VALUE data at the end of each compensation cycle. So to be any good it must work without software support.

This needs testing to confirm ...

[roland.ames]

I find myself agreeing with you again!

my point 1) was really only an answer to

What would be the point of adjusting the RTC counter only once in a cycle and then never again (so 1 seconds increment is corrected but no other second increments were corrected??)

your point on operation on battery power is good, where's the facepalm emoticon when you need it?

in the end though it will have to be tested

good luck, i will be interested to see how it turns out

Roland

[gavinm]

Some testing results ... this is using my full application code, but with a few temporary additions to monitor the RTC compensation registers.

I added this routine to my local copy of the MCF5441X_rtc.cpp utility functions ... It reads the RTC Compensation register and returns this as the least sig 16 bits of an integer and includes the CDON compensation done bit from the RTC status register in the second bit of the most sig 16 bits.
If the Compensation done bit is set, it clears it (in practice I suspect that you don't need to do this unless you want to see it toggle to confirm that the compensation is being performed).

Code: Select all

/* Read RTC Compensation Done (CDON) bit from Status Reg
 * and  Compensation INTERVAL and VALUE from Compensation Reg */
int MCF541X_GetCompData()
{
	int comp=sim2.rtc.compen & 0xffff; //Read INTERVAL (MSB) and VALUE (LSB)
	int compdone=sim2.rtc.sr & 2; //Read Compensation Done bit (bit 1 in Status Reg
	if (compdone != 0)  //If Comp Done bit is set reset it
	{                     //First enable writing to RTC (Comp Done isn't cleared if RTC is Write Protected)
		sim2.rtc.cr=0x00; //Write protect and set binary mode DST off...
		asm(" nop");
		sim2.rtc.cr=0x01; //Write protect and set binary mode DST off...
		asm(" nop");
		sim2.rtc.cr=0x03; //Write protect and set binary mode DST off...
		asm(" nop");
		sim2.rtc.cr=0x02; //Write protect and set binary mode DST off...
		sim2.rtc.sr = 0x02; // Write to Comp Done bit to clear it
		sim2.rtc.cr=0;      //Now Write protect again
		asm("nop");
		sim2.rtc.cfg=0x08;
		asm("nop");
		sim2.rtc.cr=0x02; //Write protect and set binary mode DST off...
		asm("nop");
	}
    return ((compdone<<16) | comp);
}

My "main" "while 1" loop is already repeating 4 times per second, so I've added

Code: Select all

      int compdat = MCF541X_GetCompData();
      iprintf("RTC Compensation %8x\r\n", compdat);

Finally in the RTC setting function I've added code to set the compensation INTERVAL and VALUE to the previously calculated 4 sec interval and +5 32kHz counts compensation.
(Obviously this needs to be in the section after Write enabling the RTC registers!). In a real application these numbers would probably come from some parameters that can be edited via a web page or however else you allow users to edit data in your application.

Code: Select all

sim2.rtc.compen = 0x0405;

So monitoring the standard o/p text in MTTTY I get (exactly what I hoped for / expected!)

RTC Compensation 405
RTC Compensation 20405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 20405
RTC Compensation 405
RTC Compensation 405
RTC Compensation 405

The value is represented in hexadecimal. The "0405" is the compensation INTERVAL and VALUE being read back. The "2" is the compensation done bit from the status register.
There are several things to note ...
- once set to 0x0405 the compensation register never changes (even after a reset). SO in the Freescale Ref Manual in Table 37.21 where it says "This register is cleared when RTC_SR[CDON] is set.", this is a lie!
- Each line in the output above is printed every 0.25seconds. Note there are 16 lines (4 seconds) between the compensation done bits being set. This matches the 4 sec INTERVAL setting.
- To reset the compensation done flag in the status reg the line "sim2.rtc.sr = 0x02; // Write to Comp Done bit to clear it", writes a "1" to the compensation bit to clear it. It does not clear when the status register is read as suggested in section 37.4.10 "The compensation done bit is cleared on reads." (probably just a typo and the "read" should be "write"). AND it is worth noting that the RTC must be enabled for writing otherwise it doesn't clear (obvious I suppose).

BUT - is the RTC really being compensated? Well to avoid waiting days to find out, I've changed the compensation to maximum. Compensate by 127 counts every 1 second.
INTERVAL = 1, VALUE = 127.
As predicted my text output changes to

RTC Compensation 17f
RTC Compensation 2017f
RTC Compensation 17f
RTC Compensation 17f
RTC Compensation 17f
RTC Compensation 2017f
RTC Compensation 17f
RTC Compensation 17f
RTC Compensation 17f
RTC Compensation 2017f

Compensation done bit now set every 4 * 0.25 = 1 sec, Value = 0x7F = 127.
I calculate that this should mean that the RTC will gain 2.3sec in 10 minutes of real elapsed time.
... 10 minutes later ...

Well well well ... indeed the RTC has changed by about 2 seconds - BUT IT'S GOT SLOWER NOT FASTER ...
In the manual section 37.6.1.2 it says the RTC hardware ...

...comprises of a simple counter which divides the 32 kHz clock down to 1 Hz by counting up to 32,767. To add or remove pulses the start point of the counter is shifted and the counter still counts up to 32,767 to generate a balanced 1 Hz clock

So I assumed if I changed the start point of the counter to +127, it would need to count 127 of the 32kHz pulses LESS to reach the target of 32767 and thus would trigger the 1 seconds increment of the RTC earlier and appear to gain time.
(Conversly I assumed that a negative starting point would need more pulses to reach 32767 and thus loose time).
But that seems far too logical for Freescale, it seems to work the opposite way round ...!!
As a check I've changed the +127 to -128 every second (0x0180), and checked over 10 minutes again

RTC Compensation 180
RTC Compensation 20180
RTC Compensation 180
RTC Compensation 180
RTC Compensation 180
RTC Compensation 20180
RTC Compensation 180

... and sure enough the RTC is now gaining time by about 2s every 10 minutes.

Final test - for now. I've edited the code so the Compensation done bit is not reset by software. ie will the compensation carry on working if this bit is just left set all the time - so no additional software support is needed other than writing the compensation values once at some points (probably when the RTC is initially set).
So my text output becomes (Compensation bit "2" on all the time), Compensation -128 counts every 1 second.

RTC Compensation 20180
RTC Compensation 20180
RTC Compensation 20180
RTC Compensation 20180

... later ...
The RTC is still being compensated and gaining time. It has gained 6 seconds in 25 minutes, which is about right for 2.3 seconds in 10 minutes.

[roland.ames]

Great work, I guess the only test left is to verify the compensation works the same while the clock is running off the battery!

I think you have saved me at least a couple of days of wheel-reinventing as I would have had to do the same tests myself eventually.

Whether you write it up or not is up to you but for most people just being able to read these posts would be enough.

Thanks again.

Roland