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.

MSP430F6736: RTC_C clocksource in case of XT1 failure and power off

Part Number: MSP430F6736
Other Parts Discussed in Thread: , TIDM-AUX-MODULE

Hello everybody,

our design contains a battery attached to AUXVCC3 to use the  MSP430F6736 RTC_C module. A external 32768Hz Crystal with +-20ppm is used to drive the RTC.

Some of our device now show a clock error of several minutes after a few days. An analysis shows, that on those devices the OFIFG is set.

I suppose that in this case REFO is used as RTC clock source? Am I right?

What puzzles me most is that all those devices were switched of for most of the time. So my expectation is that the RTC should show a clock error of several days or have lost the time.

Instead it seems that the RTC was still clocked from REFO which was sourced from the battery?

A lot of question marks :-) Can someone explain what has happened? 

Thanks in advance! Best regards

  • Hello Christoph,

    A couple of things here. To confirm, are you using the MSP430F6736 (non-A version) or the MSP430F6736A?

    Normally, on an LFXTAL failure within the Unified Clock System, REFO is used as a fail safe. However, the RTC_C module does not go through the UCS and takes its clock signal from the LFXTAL (XT1). This means there is no fail-safe for RTC_C.  Also, it seems you have a battery on AUXVCC3. This means the RTC_C module will keep counting even if you remove power from DVCC because the AUXVCC3 line is still being powered via battery. The AUXVCC3 line powers XT1 and the RTC_C module.

    What you could be running into is what is described within section 3 of the following application note. Differences Between MSP430F67xx and MSP430F67xxA Devices. The TIDM-AUX-MODULE is also a good resource for setting up and using RTC_C + AUXVCC3.

  • Hello JH,

    thank you for the answer. Yep, it is a MSP430F6736, not a MSP430F6736A.
    And to clarify, the issue is fixed (cause was UCS11 from the errata sheet). Now all devices 'produce' a clock error around 1 or 2 seconds per day.

    What I still want to understand is how a clock error of up to 2 minutes per day could emerge when the RTC was sourced only by the battery?
    Is it possible that the OFIFG and XT1LFOFFG influence LFXTAL (XT1) in such a manner?

    Best regards
  • Christoph,

    It is possible some combination of the fault occurring and your main program could cause this extra delay. Please see the fallowing from the user guide in the RTC_C section 24.2.9

    If the RTC_C is enabled (RTCHOLD = 0), the 32-kHz oscillator remains active during LPM3.5. The fault
    detection also remains functional. If a fault occurs during LPM3.5 and the RTCOFIE was set before
    entering LPM3.5, a wake-up event is issued.

    I can see the part going into LPM3.5 then getting woken up again due to this. If the module is not handling correctly as described in the app note I linked to earlier, then I could see some delays happening.

**Attention** This is a public forum