This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5529: Real-Time Clock Interrupt Behavior with Respect to Real-Time Clock Calibration

Part Number: MSP430F5529
Other Parts Discussed in Thread: MSP430FR5994,

I am developing a data logger that is designed to take a measurements from two different sensors (A and B) and store them.  Sensor "A" records at 1 Hz and sensor "B" at 64Hz. The values are not tagged, they are simply stored as it is collected in a repeating pattern"ABBB...ABBB... etc.), so in order to decode the data the pattern must repeat without fail. The code uses the RT1PSIFG to generate the 64Hz interrupts for the data collection and storage. The timing for the 64Hz sensor is tight, but it works most of the time (see below).

The logger is designed to run for months at a time and the accuracy of the clock is a concern. So the 32768 Hz watch crystal is calibrated against a reference.  The crystals generally run about 32 ppm slowly, so to compensate  RTCALS is set to 0 and RTCCAL is set to 4 (+32 ppm of adjustment per the erratasheet).  The accuracy is about right.  No issue there.

The problem is that every 64 minutes, without fail, there is a glitch in the data where the 64Hz data is bad and it looks like one or more of the 64Hz measurements from sensor B is missing. The RTC Calibration is the #1 suspect because it is the only event that occurs on a 64 minute interval.  I have read and re-read the user guide to understand the issue and try to find a solution but I don't quite understand and I need some help.  The relevant section of the user guide reads: 

Calibration is accomplished by periodically adjusting the RT1PS counter based on the RTCCALS and
RTCCALx settings. In calendar mode, the RT0PS divides the nominial 37268-Hz low-frequency (LF)
crystal clock input by 256. 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.

If I understand this correctly, RT0PS is feeding the RT1PS at 128Hz, so the 64Hz interrupt is triggering for every 2 counts out of RT0PS.  To adjust the clock, every 64 minutes, the RT1PS is either held for a number of RT0PS counts (creating a long "1/64th" of a second or it is pre-loaded with a value greater than 0 to speed up the clock (creating a short "1/64th" or a second).  In my case, with a nominal crystal of that is 32 ppm slow, the RT1PS would be need to be preloaded with a value of 4 (or is it 8?) and that would then result in 2 missed interrupts.  Or to put it another way, the "64Hz RT1PS interrupt" would only trigger 62 times during the "calibration second"?  Is this interpretation correct? If not, what am I missing? 

The minimum adjustment is -4/+8 ppm.  So even if the 32768 crystal was exactly on target, there would still be a timing glitch every 64 minutes. Right? Is there any work around to assure that there are 64 interrupts in each and every second?

Thank you for the assistance.

  • would it be good enuff if you could simply guarantee the 64 to 1 logging ratio even if the logging isn't exactly x million sets of data over x million seconds?
  • That would work from a data parsing perspective, but the clock would not be accurate over time, so the time stamps would be drifting over time.
  • You don't have to give up the calibration, I think you just need a counter in the fast ISR so you can skip or do extra 'fast' data logging now and then IAW the logging of the 1 HZ events.
  • My basic question was does the RTC calibration work in such a way that it is possible that there will be either extra or too few 64Hz interrupts in a 1-second period every 64 minutes. Based on your answer, you seem to be agreeing this this interpretation of the user guide. Is that your understanding of how it works? I want to be sure of the cause of the problems before nailing down the solution.
  • yep, you've got it unless I myself have been mistaken on how this works (possible). 'leap cycle(s)' can and will be added or subtracted unless the cal data registers are  zero.

  • The user guide states that "The minimial calibration possible is -4 ppm or +8 ppm. For example, setting RTCCALS = 0 and RTCCAL = 0h would result in a -4 ppm decrease in frequency. Similarly, setting RTCCALS = 1 and RTCCAL = 0h would result in a +8 ppm increase in frequency." So it appears that there is no avoiding the "leap second". In fact, as a minimum, there are 2 missing 1/64ths interrupts every 64 minutes or 4 extra 1/64th of a second interrupts per 64 minutes.

    I find it hard to believe that the RTC is designed to work this way. Hoping someone else has an alternative explanation, though I am not optimistic.
  • Nick,

    By reading your previous posts and referencing Katie's posts in another similar e2e thread, it does sound like the root cause of missing one or more sensor readings every 64 minutes is from the calibration module holding the RT1PS counter for one or more clocks of the RT0PS output.

    The purpose of the calibration module is to allow a user, only in Calendar Mode, to perfectly calibrate the RTC input to accurately measure seconds, minutes, hours, etc. over time. In your case, you want to accurately time interrupts that trigger every n seconds on the RTxPS interrupt flag without having to worry about the calibration module affecting those interrupts. This sounds like a perfect application for the RTC in counter-mode.

    Your best bet is to clear the RTCMODE bit to put the RTC in counter mode that way the calibration module is deactivated and you would not have to worry about it affecting the Prescale interrupt timing. Since you are not tagging the sensor data and only need to decode the repeating data pattern, this configuration of the RTC peripheral should work for your implementation.

    Best regards,

    Matt Calvo

  • It does look like this specific problem could be solved by using the RTC in counter mode.  But that would be a big change and would have several negative side effects.  Specifically:

    1. The clock will no longer be accurate over time.  This is a particular issue because typically multiple data loggers are typically deployed for months at a time and the data should be reasonable synchronized. We have added temperature compensation to the calibration values.  Without the RTC compensation, the clock drift between any two data loggers would exceed our target.

    2. The data logger has several operating modes and does not always record continuously.  The calendar mode is useful for setting a wake up time and maintaining low power operation between measurements.

    3. While the data file is stored in a repeating pattern, the logger still needs to keep track of the time for other reasons, such as communicating with other devices, that are beyond the scope of this discussion.

    So there are several reasons that I am not ready to give up on RTC Calendar mode. Furthermore, I still have hope that there is a work around that provides the best of both worlds.

  • Nick,

    Your need to have a sense of time makes sense and I totally understand that is the root purpose of your inclination to stay with the RTC in calendar mode. The resolution of the calendar mode is in the interval of seconds. Using it to trigger interrupts 64 times per second is feasible using the RTxPS interrupts, but it is limited by the need to have the calibration module hold the RT1PS counter for a certain number of cycles every 64 minutes (which is needed to maintain accuracy over time).

    From what I can see in the User's Guide, the output of the RT1PS counter is what is affected by the calibration module. Perhaps a possible workaround would be to use the RT0PS interrupt capability to trigger the sensor data acquisition for your 64Hz application. As can be seen in Section 22.2.3.1, the RT0IP bits are capable of triggering the RT0PSIFG as slow as 128Hz. In your case, you could disregard every other interrupt in order to end up with a reliable 64Hz interrupt counter that is sourced from RT0PS.

    Best regards,

    Matt Calvo
  • Nick,

    Has there been additional developments for this issue or perhaps a resolution has been found? I was looking into the newest RTC version (RTC_C) which is provided on the MSP430FR5994 and that version of the calendar mode seems to fix the issues we are seeing arise on your project implemented on the RTC_A. For the RTC_C, there is no "minimum possible calibration" as we saw on the User's Guide for the RTC_A peripheral. Thus it seems that the RTC_C can be used in calendar mode without intervention by the calibration correction. Some other perks achieved by using the FR5994 is the FRAM transition which has benefits far greater than Flash based memory in addition to having peripherals like the Low-Energy Accelerator to assist in low power signal processing.

    Best regards,

    Matt Calvo
  • A resolution has not been found.  The current state could be defined as confusion.   By the way, It is not possible to switch to the MSP430FR5994 (or any other version) because this is a deployed product.

    Here is my current thinking:  We typically set RTCALS to 1 and RTCCAL is set to 4  which results in a correction of + 32 ppm.  I have verified that this calibration works by comparing the clock to a reference with and without the RTC correction over a period of days/weeks.  The clock adjustment works at a macro scale.  But I don't think the exact adjustment method is adequately described in the user guide.

    The +32 ppm shift equates to removing 4096 T0PS cycles per 64 minutes, or 16 increments of the RT1PS counter (per section 22.2.4, second paragraph).  That would be 16/128ths or 8/64ths or 1/8th of a second. I had previously assumed that the adjustment occurred all at once and a jump of that magnitude would be really obvious.  But a close read of the datasheet does not say that. Rather, it says the cycles are subtracted "every 64 minutes".  It seems likely that the increments are spread out over the 64 minute interval, one 1/128ths of a second at a time until 1/8th of second of total adjustment has been made.  I have two reasons for thinking this:

    1. An older version of the hardware that uses a different, faster sensors, works at 64Hz. Significantly, it does not have "leap seconds" where one 1/64th of a second is missing (never mind 1/8th of a second). (If it did the data file pattern would not not hold and parsed file would be corrupt.)  Presumably there is enough margin that the system can manage a short cycle (1/128th vs 1/64th) without dropping the data.

    2. On the newer, slower, hardware that is more timing dependent, the data file errors show up as a pattern of errors every 64 minutes.  It seems likely that this slower hardware can not manage the short cycles.  Furthermore, the errors always occur on the same fraction of a second, even on different hardware, specifically 38.875 and 58.875 seconds into each minute.  The number of errors is hardware specific and varies with the RTCCAL values. I am guessing that the RT1PS counter must be hard coded to incremented on the 38th and 58th second and the number of errors in the data file is proportional to the number of short cycles.

    That is what I think is happening, but I tried to confirm it by capturing a short cycle on the oscilloscope. To do so, the code was modified to togging an output based on the RT1PS 1/64th interrupt.  The scope is set to trigger on a short cycle (i.e. a cycle that is less than 1/64th of a second or 15.6 mS).  I expect to see a cycle that is only 1/128th of a second long, but so far, I don't see any short cycles even after running for much more than 64 minutes, so the theory has not been proven, hence my confusion.

    But the bottom line question is: Do positive RTC compensation values result in "missing" 1/64th interrupts or are there "short" 1/64th interrupts?  The solution will depend on the answer.

    Thank you for your response.

    Nick

  • Nick,

    I am going to reach out to our Systems Engineering team who specialize in the RTC peripheral to see if they can shed some light on the issues you are seeing arise in your design and to inquire about some potential workarounds or solutions. I will reach back out to you when I hear back from them. Thank you for your patience!

    Best regards,

    Matt Calvo

  • Any word from the System Engineering team on the RTC behavior?

    Thanks,

    Nick

  • Nick,

    As most TIers returned from holiday yesterday, I am hoping to hear back from them soon. I will go ahead and ping them again to expedite a response.

    -Matt Calvo
  • Nick,

    As the systems owner is being contacted for this matter, their initial concern was to make sure that the RTCALS bit is being set to 1. This was the first question because in your initial E2E post, you stated that RTCALS is set to 0. I am thinking that was just a typo in the initial post but I want to be certain.

    Thanks,

    Matt
  • Good catch.  That was a typo. RTCALS is set to 1.    Complete register below:

  • Nick,

    Thanks for the clarification! The next question is whether you are using the RTC in Binary (hexadecimal) code mode or in Binary coded decimal (BCD) mode?

    Best regards,

    Matt Calvo
  •  BCD.  Here is the entire RTC set of registers (trying to get ahead of the questions).

  • Nick,

    Thank you for sending that info. It would help the debug process if we could replicate the issue you are seeing using one of our MSP430F5529 Launchpads. Would you be willing to send me your source code, or at least a stripped down version that incorporates the issue, along with instructions on how we can observe that the problem exists.

    Best regards,

    Matt Calvo
  • Nick,

    I emailed you about getting the stripped down source code. I will be keeping an eye out for your reply.

    Best regards,

    Matt Calvo
  • Nick,

    Since we are taking the support of this issue offline, please go ahead and select that this post resolved your issue so that I can close out and log this thread.

    Best regards,

    Matt Calvo

**Attention** This is a public forum