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 on F53xx - couple minutes drift

Other Parts Discussed in Thread: MSP430F5342

Hi!

I program RTC module on MSP430F5342 with code from MSP430F543xA Code Examples. ACLK (32768 quartz) run RTC. 

After one day running CPU in LPM3 and update RTC time to LCD every minute, I get a couple of minutes error. What could be wrong for so much big error in one day?

Internal cup for XTAL is default (12.5pF). I measure quartz and it is in predicted range (32768.xx).

Any suggestions or ideas?

  • Most likely the problem is caused by bugs in the RTC code or interrupt latency generated by other code. But it is also possible that the crystal oscillator is not working or occasionally stops. The "failsafe"  feature of the hardware hides the oscillator failure and fooled the RTC code.

    Was the RTC too slow or too fast?

  •  

    There is no other interrupts in code, just "one minute"  RTC interrupt witch write time on LCD.

    RTC time is faster that should be. I've 10 identical PCBs, and there is the same problem at all teen. So could be software? Is possible that RTC didn't work with ACLK (32768Hz), insted that RTC work with DCO or VLC?

  • I am just guessing, the 32768Hz crystal controlled oscillator is not working and the "failsafe" feature fooled you and your code.

    To verify my theory, remove or short circuit the crystal and see it behave the same.

  • Hello,

    I did inplement an RTC with external clock on ACLK as well, in my case I did try around couple of weeks with different settings for the XT2 slow oscillator settings, like drive strength and os on.

    Furthermore I did use a clock crystal from microcrystal, they got app notes for every crystal and MSP430 used, so applied those settings and I am pretty sure my clock runs pretty fine, perhaps couple hours wrong in one year, but as I write this, I must say this is pretty close to what you write.

    1 minute a day = 365 minutes a year = 6 hours wrong.

    Microcrystal offers you to measure your pcb traces to their crystal and look after your load capacitances for you, perhaps there might be some bugs in your PCB layout or MSP430 settings.

    Your clock can only go right if your crystal has exactly the right frequency, and this will practically never be the case,because of temperature and so on..

    Hope that helps a bit.

  • You could consider +/-10sec per day range as a normal behaviour for an uncompensated, unoptimized crystal reference. One minute a day is very important.

    For example setting XCAP for 12,5pf with a 6pf crytal will vary the frequency for approx -5s/j only

    The interrupt latency is not a problem as the next interruption is set as with the CCR and not with an offset on the timer running during isr.

    It is possible to set a calibration value in one of the RTC_A register, perhaps you set a wrong value. Anyway the maximum modification is 64ppm, wich only represents -5.5s/j.

    For information 60s/d is -700ppm (= 0.07% frequency deviation, wich is too tight for having such repeatability if you were running from REFO), compared to the +-20ppm of a standard quartz at room temp:)

    Could you share the layout and some initialization code wiht us? This will help.

  • Thank you all for all ideas, problem is solved for now!

    Problem was in software (quartz settings).

    In the beginning, I used that kind of code (witch is obviously wrong) to initialize 32768 quartz :

    // Set MCLK, SMCLK, ACLK
    UCSCTL4 = SELS0 | SELS1 | SELM0 | SELM1;// MCLK = SMCLK = DCO, ACLK = 32kHz
    // ACLK = 32768kHz
    P5SEL |= (XIN | XOUT); // P5.4, 5
    UCSCTL6 &= ~(XT1OFF); // XT1 On
    UCSCTL6 |= XCAP_3; // Internal load cap
    do
    {
    UCSCTL7 &= ~XT1LFOFFG; // Clear XT1 fault flags
    }while (UCSCTL7&XT1LFOFFG); // Test XT1 fault flag



    After that I found "MSP430F543xA, MSP430F541xA Code Examples (Rev. C)" and right code for initialize 32768 quartz.
    I also give MCU a little delay to settle down quartz at power on :

    // Set MCLK, SMCLK, ACLK
    UCSCTL4 = SELS0 | SELS1 | SELM0 | SELM1 | SELA_0;// MCLK = SMCLK = DCO, ACLK = 32768kHz
    P5SEL |= (XIN | XOUT); // P5.4, 5
    UCSCTL6 &= ~(XT1OFF); // XT1 On
    UCSCTL6 |= XCAP_3; // Internal load cap
    delay_ms(100);
    // Loop until XT1,XT2 & DCO stabilizes
    do
    {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
    // Clear XT2,XT1,DCO fault flags
    SFRIFG1 &= ~OFIFG; // Clear fault flags
    }while (SFRIFG1&OFIFG); // Test oscillator fault flag


    Now RTC work fine. Deviation of time is in tolerance borders of quartz.



    Later I dig a little deeper in RTC module. I think I found a little bug in code examples "MSP430F543xA, MSP430F541xA Code Examples (Rev. C)", in "msp430x54xA_RTC_02.c" example, when you initialize "Day Of Week".
    In data sheet of RTC, for Day Of Week register write that days are marked from 0-6 [0 = Monday, 1 = Tuesday...].
    But in code example "msp430x54xA_RTC_02.c" Monday is marked with "0x01".
    Should Monday be commented by "0x00" ?

  • MihaKorošec said:
    ...

    In the beginning, I used that kind of code (witch is obviously wrong) to initialize 32768 quartz :

    // Set MCLK, SMCLK, ACLK
    UCSCTL4 = SELS0 | SELS1 | SELM0 | SELM1;// MCLK = SMCLK = DCO, ACLK = 32kHz
    // ACLK = 32768kHz
    P5SEL |= (XIN | XOUT); // P5.4, 5
    UCSCTL6 &= ~(XT1OFF); // XT1 On
    UCSCTL6 |= XCAP_3; // Internal load cap
    do
    {
    UCSCTL7 &= ~XT1LFOFFG; // Clear XT1 fault flags
    }while (UCSCTL7&XT1LFOFFG); // Test XT1 fault flag
    ...

    I think the register settings are correct. Only the code to clear the error flags is wrong.

    MihaKorošec said:
    ...  Monday is marked with "0x01".
    Should Monday be commented by "0x00" ?

    I have two questions:

    1. Are the days of the week represented by [0,1,2,3,4,5,6] or [1,2,3,4,5,6,7]?

    2. Is Monday or Sunday the first day of the week?

  • 1. Are the days of the week represented by [0,1,2,3,4,5,6] or [1,2,3,4,5,6,7]?

    I think that days of the week are represented by  [0,1,2,3,4,5,6]. This is written in data sheet (Real-Time Clock Day of Week Register (RTCDOW) – Calendar Mode).

    2. Is Monday or Sunday the first day of the week?

    It seems that first day of the week is Sunday! If you look at Example 4 in "Real-Time Clock Alarm Function", there say that Tuesday is "0x02".

    So, there is no error in two post back mentioned bug in code samples. 

    I usually start week with Monday, so I didn't think of it:)

     

  • MihaKorošec said:
    2. Is Monday or Sunday the first day of the week?

    Since it is a matter of interpretation by the software, it doesn't matter at all. DOW is just set to a value and incremented by teh RTC. The RTC doesn't calculate whether a specific date is a specific weekday. If the applciaiton wants, it can interpret wednesday as first day of week (0). As long as the RTC is initialized this way, it doesn't matter.

    Or in other words: Day of week is just a counter that counts at midnight from 0 to 6and then begins with 0 again. What you call 'first' and what name you give it, is purely by the application.

**Attention** This is a public forum