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.

Accuracy RTC/timers in long time periods

Other Parts Discussed in Thread: MSP430F5438A, SIMPLICITI

Hi,

First of all, we are working with a custom board with MSP430F5438A device.

Our project consist in a board with data capture and communication capabilities. During long period (maybe hours or days) it will be sleeping and it will wake up for capture and communication (second or minutes depending on acquired/transferred data ).

We have observed that after some days of work, the devices start to lose the correct waking up time, that is to say, it wakes ups before/after of exact moment. For example, it powers up at 00:00:00, and few days after, it wakes up at 23:59:50 or 00:00:07 (we expect a waking up every day) and this deviation increases each day.

All timers are sourced to the ACLK, XT1 is an ABS06 device without external capacitors populated (typical load capacitance on datasheet is 12.5 pF). A summarize of UCSCTL6 is:

XT1DRIVE = 0x00

XTS = 0

XCAP = 3 // internal 12pF capacitance according to users' guide

XT1OFF = 1; // Since ACLK is sourced, this would not have relevance

Moreover during the initialization of the system, next loop is done (obtained from SimpliciTI BSP):

while ( (SFRIFG1 & OFIFG) )
    {
        UCSCTL7 &= ~(XT1LFOFFG + DCOFFG);
        SFRIFG1 &= ~OFIFG;
    }
    UCSCTL6 &= ~(XT1DRIVE_3);               // Xtal is now stable, reduce drive strength

Without this loop, the watchdog timing does not match.

All timers are calculated in their compare register to obtain an integer value, that is to say,  an "exact" second/minute, take in account the " " symbols :-).

TimerA that counts the sleep period is always running and the RTC as 32-bit counter too. When it is required the reading of RTC register, we stop it to ensure the value, could this affect at the rest of timers? Would it be better check for the secure reading flag?

We are going to check the timing formulas to get the sleeping period, maybe they could be improved, but my doubts are:

- Is this deviation normal in this "short" period? I have to mention that the timer that counts the sleeping period, moreover sourced to ACLK has a /8(TAIDEX_XX) * /8(ID_XX) prescale

- Problem produced by XT1 and the no presence of external capacitors?

- Would it be necessary to implement a timing correction function? I know that RTC in calendar mode has a calibration, but it is not available for other modes and I do not know how I could implement a custom calibration if it would be necessary.

Any idea or explanation that could help me will be well received. Thanks in advance.

 

  • Is T da S said:
    - Is this deviation normal in this "short" period?

    Depends on crystal specs. 10 seconds in few (two) days is: 10/(60*60*24*2) = 5.8*10^-5 =  58ppm which for 100ppm accuracy crystal is kinda ok. What's yours? That's why RTC clocks shall have some (software) tuning for crystal initial inaccuracy correction. Temperature drift correction shall be considered either.

    Is T da S said:
    XCAP = 3 // internal 12pF capacitance according to users' guide

    You shall test other values too, check results.

**Attention** This is a public forum