MSP430's RTC calibration, unexpected effect

Did you chekc the device errata sheet?

On teh 54xxA, there is an erratum RTC4, which states that the clock calibration may be offset by + 2ppm (in both directions)

I did check the errata sheet.

Jens-Michael Gross said:

On teh 54xxA, there is an erratum RTC4, which states that the clock calibration may be offset by + 2ppm (in both directions)

The title of the erratum RTC4 is a bit unclear. The detailed description states that this 2 ppm offset applies to the RTCCLK signal, the one used as calibration signal.

Furthermore, I get -13 ppm with compensation setup for a crystal at +14 ppm. This is much more than 2 ppm wrong.

Hi Gauthier,

from your description it is not clear how often you perform the calibration. However you have to consider that the RTC_A has a calibration Period of every 64 Minutes. But you set an callibration value for 14 days.

From the F5xxx Family User's Guide:

A 64-minute period has 32768 cycles/sec × 60 sec/min × 64 min = 125829120
cycles. Therefore a –2-ppm reduction in frequency (down calibration) approximately equates to adding an
additional 256 cycles every 125829120 cycles (256/125829120 = 2.035 ppm). This is accomplished by
holding the RT1PS counter for one additional clock of the RT0PS output within a 64-minute period.
Similary, a +4-ppm increase in frequency (up calibration) approximately equates to removing 512 cycles
every 125829120 cycle (512/125829120 = 4.069 ppm). This is accomplished by incrementing the RT1PS
counter for two additional clocks of the RT0PS output within a 64-minute period. Each RTCCALx
calibration bit causes either 256 LF crystal clock cycles to be added every 64 minutes or 512 LF crystal
clock cycles to be subtracted every 64 minutes, giving a frequency adjustment of approximately –2 ppm or
+4 ppm, respectively.

Forthermore it is not clear when exactly you read the RTC register values. Because the system clock may be asynchronous to the RTC_A clock source, special care must be taken when accessing the real-time clock registers.

From the F5xxx Family User's Guide:

When the counter clock is asynchronous to the CPU clock, any read from any RTCSEC,
RTCMIN, RTCHOUR, RTCDOW, RTCDAY, RTCMON, RTCYEARL, or RTCYEARH register
while the RTCRDY is reset may result in invalid data being read. To safely read the counting
registers, either polling of the RTCRDY bit or the synchronization procedure previously
described can be used. Alternatively, the counter register can be read multiple times while
operating, and a majority vote taken in software to determine the correct reading. Reading
the RT0PS and RT1PS can only be handled by reading the registers multiple times and a
majority vote taken in software to determine the correct reading or by halting the counters.
Any write to any counting register takes effect immediately. However, the clock is stopped
during the write. In addition, RT0PS and RT1PS registers are reset. This could result in
losing up to 1 s during a write. Writing of data outside the legal ranges or invalid time stamp
combinations results in unpredictable behavior.

Since you mentioned that you are operating in the LPM4, it would be also helpful to see if you still face this problem when opeating in Active mode.

Best Regards,

Mo.

Gauthier ��stervall said:

Furthermore, I get -13 ppm with compensation setup for a crystal at +14 ppm. This is much more than 2 ppm wrong.

I did misinterpret your values. I was thinking the second value was the relative change due to calibration, not the new error.
It look sliek the adjustment is by a factor of 2 stronger than expected. While I don't know why, my sugestion how to solve this would be: just assume a +8/-4ppm adjustment per LSB. If this gives good results then, well, then there' ssomething wrong but the code is working. :)
Of course it is better to know why things work, but just having them working is better than having them not working and not knowing why ;)

Mo. said:

from your description it is not clear how often you perform the calibration. However you have to consider that the RTC_A has a calibration Period of every 64 Minutes. But you set an callibration value for 14 days.

I am not sure what you mean. I like to separate the two concepts of 1. calibration (finding the crystal error, calculating the matching register settings, and setting the HW register to these settings) and 2. compensation (this is done in hardware every 64 minutes, according to the registers setup in 1.).

With these definition, I perform the calibration only once. Then the compensation period is 64 minutes, but the hardware manages this.

"you set an calibration value for 14 days" -> no, I set the calibration value once, and it should be applied forever every 64 minutes until I change the registers.

Mo. said:

it is not clear when exactly you read the RTC register values.

I do not read the register values for current time by hand. The RTC time registers are read by the core (in a RTCRDY ISR), then shown on an LCD. With a +14 ppm crystal error, the time displayed on the LCD is 18 seconds off compared to the reference after two weeks.

Mo. said:

it would be also helpful to see if you still face this problem when opeating in Active mode.

It sure would. But note that with no compensation (zeroed calibration), the time display is off by exactly the measured crystal error after two weeks. Still, if LPM affects a non-zero compensation, and does not affect it if zero, then I should see a difference.

Jens-Michael Gross said:

If this gives good results then, well, then there' ssomething wrong but the code is working

This is why I hoped someone here would tell me that this is what they did (halved their calibration and saw it work).

The section RTC6 of the new errata now mentions that the User Guide was wrong:

Function the step size of the RTC frequency adjustment is twice the specified size.
Description The step size of the RTC frequency adjustment is =4ppm/-8ppm. This is twice the size
specified in the User's Guide.
For up calibration this results in a step size per step of 8ppm (1024 cycles) instead of
4ppm (512 cycles). For down calibration this results in a step size per step of 4ppm (512 cycles) instead of 2ppm (256 cycles).
Workaround Half the calibration value written into RTCCAL register to compensate the doubled step
size.

This was expected, but it's good to see TI confirm. It's sad to realize how much time I have spent on this issue, though.

I wonder how this went through verifications, and other users of the RTC. Surely, the compensation must have been used by others? Didn't they notice it was wrong? Or did they notice and said nothing? Maybe they thought they misunderstood, gave up, and used an alternative solution?