• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 78 subscribers
  • Views 1579 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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

Christoph Schweers
Intellectual 475 points
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
Christoph

  • 0
    TI__Guru 56685 points

    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.

  • 0 in reply to Jace H
    Intellectual 475 points
    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
  • 0 in reply to Christoph Schweers
    TI__Guru 56685 points
    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