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.

RTC drift

Other Parts Discussed in Thread: MSP-TS430RGZ48B

Good morning,

I'm new to doing embedded development, but have been working on an application for the F5342 chip. The program needs to have a real-time clock, and will spend most of its time in LPM3, waking up twice a second to do a little work.

I'm using DriverLib, and used the rtc_a_ex1_calendarmode example. To initialize the clock, this is basically what happens:

Calendar current;
// initialize current with the current time

RTC_A_calendarInit(RTC_A_BASE, current, RTC_A_FORMAT_BINARY);

Then to read the clock it just does this:

Calendar current = RTC_A_getCalendarTime(RTC_A_BASE);

The trouble is that it's not very accurate. It's been running about 1 hour, and the clock has already gained about 40 seconds.

So I guess there needs to be some calibration applied, but after reading a number of posts on similar problems, and being new to developing for this chip, it's not clear to me just what I should do.

Some posts seem to imply there should be an additional clock used that is more accurate than the A clock, but I need to use LPM3 and there's no additional clock available.

I have tried doing this:


And it seems to have slowed things down but it's still gaining about 20 seconds an hour.

At this point, I'm not sure what to else do. How can I make the clock more accurate?

Thanks for your help,

  • Hi Alfie,

    ACLK itself is not inaccurate, but what you are sourcing ACLK from might be inaccurate. Do you use and enable an external watch crystal on your board to source ACLK? That is really what is needed to achieve good RTC accuracy.

    You can see in the comments at the top of that driverlib example, on line 38-39, it says "This code recommends an external LFXT1 crystal for RTC accuracy." Do you have a crystal on your board? If you do not, what is happening is that the fail-safe circuitry in the part is switching the RTC to being sourced from an internal clock source instead (REFO I think) which is much less accurate than using an external crystal.

    Once you are using the crystal, to get the best possible accuracy you can use the driverlib function RTC_A_setCalibrationFrequency to output the frequency on a the RTCCLK pin to measure the frequency and determine the drift you should calibrate for, then use RTC_A_setCalibrationData to configure the RTC to account for this amount.

    I hope this helps clear things up!



  • Hi Katie,

    There's no external source available--it's a very small board. I thought I was enabling XT1 and tying it to ACLK, but maybe not. Here's how things are initialized:

    UCS_LFXT1StartWithTimeout(UCS_BASE, UCS_XT1_DRIVE3, UCS_XCAP_3, 500000);

    And after doing that when I get the ACLK frequency, it's 32768. So I think the crystal and ACLK are set up correctly, but could I be doing that wrong?

    I tried RTC_A_setCalibrationData(RTC_A_BASE, RTC_A_CALIBRATION_DOWN2PPM, 63); which I think is the maximum amount it can calibrate downwards, but the clock is still drifting too much.

    Anything else you can think of?


  • Alfie Johnson said:
    And after doing that when I get the ACLK frequency, it's 32768. So I think the crystal and ACLK are set up correctly,

    This might be not true.
    You start the crystal with timeout and don't check whether the crystal is up or the timeout occurred and the crystal is defective.

    If the crystal didn't start, the MSP will fall back to the internal 32kHz REFO, which is up to 1.5% off and also drifts with temperature and supply voltage.
    Your code won't notice.

  • Hi Alfie,

    Alfie Johnson said:

    There's no external source available--it's a very small board. I thought I was enabling XT1 and tying it to ACLK, but maybe not.

    While there are a variety of internal clocks on the 5xx devices, there is no crystal. If you are configuring your part to use XT1, but do not have an external crystal provided on your board, then you can't actually use XT1 (it requires an external crystal). Your code looks correct for setting up XT1, but you would need a crystal on your board.

    Since you don't have a crystal on your board, what happens is that the function UCS_LFXT1StartWithTimeout will hit its timeout and move on, because it will never be able to get the XT1LFOFFG to stay clear (since there is no XT1 crystal and no oscillation happening). Because the fault flag is set, the UCS module's fail-safe functionality will kick in and set ACLK to actually be sourced from REFO (please read the 5xx user's guide UCS chapter, especially section 5.2.12 on Fail-Safe Operation).

    As Jens-Michael explained, the REFO will give you 32768, but it is less accurate than a crystal and will drift with temperature and voltage. This is probably why you are seeing your drift. The best solution for an accurate RTC is to provide a crystal oscillator on the board. If you have a TI target board (like MSP-TS430RGZ48B), this has pads for a crystal on it so you could experiment with this functionality to compare if you'd like.