• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 1152 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5438A, drift on RTC and calibration

Javier Redondo
Prodigy 90 points
Other Parts Discussed in Thread: MSP430F5438A

Hi all,

I´m working with MSP430f5438A and I´ve some problems about RTC and clocks. I´ve installed a 32768Hz crystal (6pF load capacitance and 20ppm accuracy) as XT1. Then I´ve selected XT1 as ACLK.

I ´ve implemented several devices with the same components (MSP430f5438A, crystal…) and same software but there are different behavior about RTC. After a few days (5 or 6), some devices start to get a drift (only a bit of seconds). I´m worried about the drift because it isn’t lineal, every day is greater the difference, becoming several minutes only in ten days (Finally, some devices loses up to 15 minutes each day).

I noticed two wrongs settings: 1- XCAP was set up to 12pF (XCAP_3) instead of 6pF (XCAP_1). 2- I haven´t included the code for clear XT1 fault flags and test oscillator fault flag (Loop until XT1,XT2 & DCO stabilizes). Is it possible that the big drift is due to this? The rest of my program uses SMCK and MCLK were configured as DCOCLK.

It´s the code to configure the RTC, based on MSP430_WARE.

    RTC_calendarInit(__MSP430_BASEADDRESS_RTC__, currentTime, RTC_FORMAT_BINARY);   

    RTC_setCalendarEvent(__MSP430_BASEADDRESS_RTC__,RTC_CALENDAREVENT_MINUTECHANGE);

    RTC_enableInterrupt(__MSP430_BASEADDRESS_RTC__, RTCRDYIE + RTCTEVIE + RTCAIE);

    RTC_startClock(__MSP430_BASEADDRESS_RTC__);

Also I decided to measure the RTCCLK signal for calibrate the frequency. I obtained a 512,03277 Hz (generating 512Hz), it supposes 64ppm which can be calibrate each 64 minutes witch appropriates registers:RTCCALS would be cleared, and RTCCAL would be set to 16 (64/4). If I decide don´t set this calibration, it supposes a drift of 64 ppm each 64 minutes so in a month a get a drift of 1.31s. (1month x 30days x 24hours x 60 minutes) / 64 minutes x 64 ppm / 32768 Hz = 1.31s ). Is it correct?

Thank you for your time

  • 0
    Prodigy 90 points

    Hi,

    I don´t understand very well, may be you can help me... I´ve measured RTCLK and I´ve obtained 513.083633 Hz (it seem very high...). I´ve revised many registers ( XCAP_1 for my 6pF load capacitance and much others and it´s ok..). I think that I should forget something (may be a set configuration?)

    And what about the no lineal drift?? Somebody could help me, please??

    Thank you

  • 0 in reply to Javier Redondo
    Guru 227245 points

    About the basic frequency error, I can't say much. Maybe the crystal really is that much off (2000ppm).

    The drift problem after some time might be that the crystal fails. In this case, the internal REFO will take over. And unless you clear the LFOFFG and OFIFG bits again, it will remain on REFO.

  • 0 in reply to Jens-Michael Gross
    Prodigy 90 points

    Hi,

     

    Firstly, thank you for your answer. As you said, it seems that after a time, the XT1 can fault so the XT1LFOFFG is set and REFO take over. Now, I´m solving this problem, for it, I ´ve added this code for manage interrupt (clearing flags and still XT1 as ACLK):

     

    SFRIE1 = OFIE;                  // Enable osc fault interrupt

    .

    .

    .

     

    #pragma vector=UNMI_VECTOR

    __interrupt void UNMI_ISR(void)

    {

      do

      {

        UCSCTL7 &= ~(XT1LFOFFG + DCOFFG);       // Clear XT1 & DCO fault flags

        SFRIFG1 &= ~OFIFG;                      // Clear OSC Fault flag

        for (i = 0xFFFF; i > 0; i--);           // Time for flag to set

      }while ( (SFRIFG1 & OFIFG) );

    }

     

    But I´ve a question, what are the reasons for the failure of the oscillator? (I think that it fails a lot...)

     

    The user guide says “…The effective capacitance (seen by the crystal) is Ceff ≉ (CXIN + 2 pF)/2. It is assumed that CXIN = CXOUT and that a parasitic capacitance of 2 pF is added by the package and the printed circuit board. For details about the typical internal and the effective capacitors, refer to the device-specific data sheet…”.

    So for my crystal (6pF load capacitance), what is the value for XCAP register?

    Thank you in advance

  • 0 in reply to Javier Redondo
    Guru 227245 points

    The datasheet lists the effective load capacitance, including the parasitic pin capacitance but not the parasitic PCB trace capacitance. So XCAPx=1 for 5.5pF plus trace capacitance looks good to me.

    Javier Redondo said:
    But I´ve a question, what are the reasons for the failure of the oscillator? (I think that it fails a lot...)

    Crosstalk from other PCB traces (use a guard fence next to the crystal traces, and isolated GND plane below the whole area, that means a separate GND area that is connected to GND only at one pooint, so no other GND currents flow through it), other EMI influence (did you ground the crystal case?), a bad crystal (other load capacitance than the datasheet tells or with a too-low ESR).
    Also moisture or dirt.

  • 0 in reply to Jens-Michael Gross
    Prodigy 90 points

    Hi,

     

    Thank you for your answer again. You are right. I haven´t handled the oscillator fault and in consequence REFO take over (which accuracy is unluckily worse).

    Finally, I´ve a problem for manage the oscillator fault. As I said in the last post, I use that code which solve the problem (in first view) but in some situations there are flags which can´t be removed (XT1LFOFFG, DCOFFG…) and in consequence my program still in the loop.

    I don´t know if there are any tip in this situation ( like stop oscillator, restart oscillator…). Thank you for your time!

  • 0 in reply to Javier Redondo
    Guru 227245 points

    Javier Redondo said:
    there are flags which can´t be removed (XT1LFOFFG, DCOFFG…) and in consequence my program still in the loop.

    XT1LFOFFG should be clearable as soon as the crystal is running again. On 5x family, it requires a number of consecutive crystal pulses (see users guide) to allow the flag to be cleared. On older families, you could always clear it and it did pop up again after the detection timeout, so you had to wait for maximum timeout span and then check again until it stayed clear.

    DCOFFG is set if the DCO runs on it highest or lowest TAP (DCOx=0 or max). This may be caused by the FLL (if you didn'T disbale it) if the reference fails or the programmed DOC frequency is outside the current RSELx range. You can simply set DCOx to something suitable and then clear DCOFFG.

    The problem is, the different clock sources go into fallback mode individually, but you can only bring them back when all faults are resolved.
    So a DCO 'fault' (which may happen a long time after startup) won't switch LFXT1 into fallback, but ince LFXT1 is switched to fallback, both faults must be handled before LFXT1 returns from REFO back to the crystal.
    Still much better than the older MSP clock systems.

**Attention** This is a public forum