8MHz DCO Clock drift using external 32KHz crystal

Are you using the DCO output to keep time?  If so, you should probably switch to using the 32768Hz reference as your timebase.  Maybe run ACLK from the 32kHz and use a timer to keep your clock.

The DCO doesn't make for a very good time base.  Also the FLL can introduce unexpected clock skew, as a result of both normal operation and silicon bugs.

By using the 32kHz quartz crystal to keep time, your clock will be accurate to the same spec of the crystal (20ppm @ 25deg C for yours).  That's less than 100ms in an hour.

Jeff

Thanks for your answer Jeff.

I will have to clear this with our SW guys.

What do you recommend as the best way to keep time? Is it the internal RTC? something else?

Assaf

I like a software RTC a little bit better than the hardware RTC.  With a software RTC, I have better control over making corrections for calibration factors including temperature.  (Our products run through a calibration system during production to characterize the crystal.)  Also with a software RTC, you can synchronize the clock tick, which can simplify software design in some cases because the time of day won't change asynchronously.   And the software RTC works on any MSP430, not just the ones with the hardware RTC.

But either approach is fine (hardware/software RTC).  Whatever the SW guys feel like doing.

When I say software RTC I mean a periodic timer interrupt where the software (ISR) increments the clock or queues a "tick" for an RTC task etc.

Jeff

Great. Thanks a lot.

Hi Assaf,

you (or your SW guys) may want to have a look at TIs RTC Library here http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa290a

Rgds
aBUGSworstnightmare

Thanks

Another thing to watch out for is the failsafe operation of the Unified Clock System. If the MSP considers the XT1 signal suspect then this can fall back to an internal oscillator trimmed to 32.768kHz. This clock is not as accurate or stable as the external crystal, but close enough to go unnoticed until you do something timing critical.

If your XT1 crystal is slow to start up then the MSP will drop into failsafe mode almost immediately and recovering requires user software intervention. If you think you are using XT1 but still getting drift then check the state of XT1LFOFFG in the UCSCTL7 register, if set it indicates that the XT1 signal has been rejected.

Phil

Yes, Phil, the fallback is one of the two possible reasons for a wrong timing.

before trusting the crystal, the proper crystal (or general clock) startup sequence should be followed. This includes waiting for all OFFG flags become clear. If XT1LFOFFG is set, the crystal is not yet running properly (if can take up to a second, several 100ms for the startup itself and then 250ms of proper operation for the fault detection allowing the bit to be cleared by software), then the internal 32kHz clock is used. This also is the default for ACLK and the FLL (since the crystal is obviously not running after power-up, and maybe there is none at all)
However, as soon as the crystal is running and XT1LFOFFG is clear, all clocks configured for XT1 will switch back form the backup to the 'real' crystal.

So there are only two reasons why the clock is running wrong:

1) the crystal is not running at all and the internal clock is used and the software does not check/notice

2) the crystal is faulty or has a wrong load attached. This may be due to parasitic PCB capacitance or wrong configuration of the MSP internal driver capacitance. If the load capacitance is higher than expected, the crystal will swing lower. (this can be used for calibrating the crystal above factory precision, but can also bring the crystal completely to a halt).
Note: a GND plane under the crystal or the lines from crystal to theMSP is a BAD thing. Mutch parasitic capacitance, and maybe even EMI induction (currents on a GND plane do NOT run equally distributed, as one could think -  they tend to concentrate where other currents flow on the other planes)