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.

MSP430F5437 FLL trouble question

Hi all,

We are trying to use FLL, based on REFOCLK/ACLK,  to stabilized DCO for SMCLK (8MHz). Unfortunately according to UCS10 bug from errata FLL workaround not really fitted for our RT application due long delays, required by this workaround. We have tried to use XT1 clock as source for ACLK with using the TimerB as RTC. We had still clock deviations. Also we have tried to use RTC in counter mode, still same trouble - clock deviations. We have measured also clocks by scope and saw clocks deviations. Additional problem that the deviation is different from card to card(3-5 different cards). Any solution for us ?!

Thx

 

 

 

 

 

 

 

  • Hi Sergey,

    If you're trying to reduce clock deviations or "skew", then you probably want to use a quartz crystal as XT1.  Using XT1 - ACLK - Timer as your RTC is really good.

    Maybe when you tried it you didn't realize that REFO was standing in for XT1.  The UCS requires *you* to clear the XT1 fault flag (XT1LFOFFG in UCSCTL7) and then OFIFG in SFRIFG1 to start actually using XT1, and only after it is successfully oscillating and the fault-detection circuitry is satisfied.  That process can take several hundred milliseconds after power up.

    As for the FLL, I use it in my application to align my clock.  But I use in a burst just to align the clock and then I turn it off (using SCGO in the SR).  You can write a closed-loop, deterministic check to know for sure that the FLL is done steering the DCO and simultaneously to work around UCS10.  Just align the clock periodically to account for temperature and/or voltage changes.

    Jeff

  • You can check whether ther UCS10 bug really applies to your individual device. All you have to do is to wait until the FLL has settled and then check the MOD and DCO bits whether they are changed the way it is described.
    If this happens, you can switch to a higher or lower (depending on the current DCO setting) RSEL frequency band, as these largely overlap. In the very most cases, the FLL will settle to a frequency there where the UCS10 bug does not apply (MOD value not at the end).

    There´s not 100% safety that it will avoid the UCS10 on all devices, but chances are good. And for those where it doesn´t, the software can detect it too.

    however, if your approach with the XT1 crystal and timer shows clock deviation too, then it is more likely a software problem of your time-tracking code or a defective or improperly connected or used crystal and not related to UCS10 at all.

    How much is the deviation? And a rather heretic question: how precise is your reference clock? I´ve seen people judging milliseconds with their wrist watch. :)

  • Hi all,

    Thanks a lot for so detailed replies.

    When we tried to use XT1 clock we measured by oscilloscope on ACLK 32.87 Khz with skew 32.84Khz till 32 .88 Khz. Also we have checked the deviation on RTC against PC clock after long  period of time (couple of seconds skew after couple of hours).

     

    BR

     

  • Sergey Povolotsky said:
    ACLK 32.87

    This is 0.3% off of the nominal frequency. If it is really the crystal, then there's something wrong. Also the deviation is quite large for a crystal (provided that you don't put it into the oven and the freezer between two checks).

    It's possible that you're still gettign ACLK clocked by the internal REFO. If there's something wrong with the crystal, ACLK will fall back to REFO if it is configured to be clocked by LFXT1. Same for the RTC I think.

    So you need to follow the procedure for setting up the external crystals, inclucing checking the OFIFG/XT1LFOFFG bits. If it is set, then the crystal is not working properly.

    Also, double-check the load capacitance (software settign of internal one plus external parasitic capacitances). If these do not match the required load of the crystal (see crystal datasheet), this results in significant detune and instability of the oscillation.

    My experience with 32kHz crystals is that I can easily get  precision of <1s/day (~0.00116%) with an adjustable capacitor and a software comparison loop on my good old C64 (~1MHz system clock, 9 clock cycles loop jitter). And even better with the 10MHz reference clock I have now, 20 years later. So it shouldn't be a problem to get decent precision.

**Attention** This is a public forum