RTC clock "slip"

Todd Anderson78572 said:

It appears that when a USB connection is made

I can image that a suddenly voltage rise gives problems for the oscillator. You can try to put a series resistor of about 200 Ohm from Vusb to the regulator. If this keeps the oscillator running you can replace the resistor by a small sized NTC, I guess somewhere between 100 and 2000 Ohm and less then 100mW.

Todd:

You might have already checked on this, but as you might know, the clock system may have selectable load capacitors. An improperly selected capacitor might be causing the drift which leads to a fault.

Leo, Thomas:

Thanks for your feedback. Yes, the load capacitors have been sized correctly for the crystal that is being used. And when working, I get a very good indication of RTC time. However, I am still chasing down why I am seeing an occassional time slip, due to what looks like a change from the external crystal to the REFO. In each case where I am seeing the time slip, the time errors on the plus side - that is, the system time is always slower than the unit time. And there is a corresponding increase in the amount of logging memory being used, so it looks like the unit is in fact being clocked at an incrementally higher rate.

I am not able to look at the RTC output clock on these units, but I am able to look at ACLK, and when the external crystal is being used, the ACLK will measure 32768.5 Hz, with some minor variations. When REFO is defaulted due to a XT1 fault, the ACLK will measure 33000 Hz, so that would account for the change in unit time over a one day period, and also account for the increase in logging memory usage.

I am now in the process of logging XT1 crystal faults, and I have not seen any faults, nor have I seen any time excursions on several units over the past several days. So, the jury is still out on just what is causing this...

Todd:

So it looks like some event is occuring behind the XT1 Fault Detection circuit (in the OSC module). It looks like the sources for such an event can be from

1. The XT1BYPASS multiplexer,
2. the crystal,
3. the XTS subcircuit,
4. the circuits that interconnect those components, and
5. the firmware.

So, a good place to start would be by answering these questions.

• Are you absolutely confident that the external crystal and its connections to XIN and XOUT are good and reliable?
• Are the solder joints good?
• When you remove power from the system, then check the continuity through terminals XIN and XOUT while mechanically vibrating the crystal canister, is the continuity good?
• Does the canister for the crystal look in good shape?
• Have all physical, electrical, and EM interference been ruled-out?

If that stuff is OK, then we need to start diagosing the problem from a firmware perspective.

Leo:

It looks like Vusb is grounded through a 0.22 pF capacitor. Did you mean to add the 200 ohm resistor to Vbus?

Tod,

I don’t know what board you are using and how easy it is to add a resistor but I meant in series from the USB connector Vbus to the 3.3V LDO input, close to the LDO there will be already a capacitor.

Thanks for clarification, Leo.

Yes, I will consider this!

This is the alternate LDO from the 5529 Experimenter's Board Schematic. We have a similar LDO. You are suggesting that I cut the line just below "_VBUS" and add a 200 ohm resistor in its place, correct?

Using the F5529 EVM and the upper right USB connector you can just replace JP15 with a resistor.

Thanks, Leo. Well stated.

Until I try this, I cannot really close out the thread, so I am not quite saying "answered."

I'm certainly interested to know if that was the solution.

Back to the original questions:

Are there any other situations besides XT1 fault that would cause REFO to source ACLK?

Also, is there anything other than the existence of XT1 fault (XT1LFOFFG in UCSCTL7) to indicate that ACLK is being driven by REFO? (If it had been initialized to run from XT1) 

Todd Anderson78572 said:

Are there any other situations besides XT1 fault that would cause REFO to source ACLK?

Well, selecting REFO as ACLK source will of course cause REFO to be used. :)

Okay, it looks like the culprit is XT1 oscillator fault. I now have code in place to

1. Check for an oscillator fault,

2. Log that it occurred,

3. Attempt to recover from the fault.

And I have seen my first oscillator fault on XT1! And the code recovered nicely, because there was no slip in the RTC time. SO, I am very happy, because until yesterday, the only way that I actually saw a fault was when I forced the fault to happen in test mode.

Good job Todd.

Todd:

Section 3.4, "Writing Handlers for Oscillater Faults" in MSP430 Software Coding Techniques is very interesting. It explains some techniques and provides code examples for handling oscillator stabilization and failure during operation. The document number is SLAA294.

Todd:

Did you ever find the cause for that slip?

So you still have the drift problem. I'm sorry to hear that.

If you plan on sticking with the MCU's built-in real-time clock, even if you solve the problem with a crystal, you'll probably have to accept some drift, maybe 2 to 15 seconds per day. But if you're like me, you want a highly accurate signal.

I'd like to suggest a very low-drift tolerance solution. I'm talking about less than a third of a second drift per day. A company in my area makes highly accurate RTC ICs that use an I²C to connect with your MCU. They're about three bucks a piece. Check it out: RTCs at Maxim. They make good stuff.

(I don't work for Maxim Integrated, nor am I a salesman.)

If the DCO creates a fault, then you’re apparently operating the DCO on the wrong DCORSEL level for the desired target frequency. Or you leave LPM for too-short periods (smaller than 2 reference clock cycles), so the FLL will misadjust the DCO. (see the errata sheet)