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.

MSP430F5438A: DCO,FLL settings after waking from LPM3

Part Number: MSP430F5438A
Basic System Operation:The system runs periodically sampling pressure and temperature sensors and then sleeps using LPM3 mode. The internal RTC is used to wake up the system from sleep.
System Clock Initialization: A custom function called init_clocks is used to initialize the system clocks at startup and in the RTC ISR. I have attached files with all functions used in the clock initialization process.
Issue: We are trying to minimize the sampling period as to offer high sensor sampling rates. Because the init_clocks routine is used in the ISR to ensure proper clock operation, it severely limits our ability to reduce the sampling period. I've measure ~135ms for the routine to run.
Question: Is it necessary to run the init_clock() function every time the device wakes from sleep? I believe all that really needs to be done is to re-enable the FLL (set SCG0) since it was turned off when entering LPM3. Am I correct? Would anything else need to be done?

  • There are two slightly different answers for the Subject: question, but I think the answer to your Question: question is the same in either case.

    In the ISR, the FLL (SCG0) is disabled, but if you turn SCG0 off, and your ISR is very long, the FLL will settle.

    If the ISR does a wakeup, in the awakened foreground the FLL will (already) be enabled, and if it runs long enough the FLL will settle. 

    In neither case is further action required. If I'm guessing correctly about what is in init_clock(), it won't do anything to speed things up. The (improbable) worst-case FLL settling time is 32^2/32768 = ~31ms.

  • Thank you for your response Bruce.

    Are there register bits to test to confirm that the FLL is settled?

  • Bruce,

    From the data sheet (MSP430F543xA, MSP430F541xA Mixed-Signal Microcontrollers), page 48, it states that the DCO turn-on and stabilization time is < 5us. I assume this includes the FLL stabilization time since it acts to stabilize the DCO. 

    The UCS module features digital frequency locked loop (FLL) hardware that, in conjunction with a digital modulator, stabilizes the
    DCO frequency to a programmable multiple of the selected FLL reference frequency. The internal DCO
    provides a fast turnon clock source and stabilizes in less than 5 μs.

    Do you think I can count on this?

  • The DCO starts up very quickly since the CPU can't run until it starts. When it starts, it has the same settings as when it stopped.

    FLL settling (in general) takes quite a bit longer. It times the DCO and Reference for 32 Reference clock ticks (~1ms), then (maybe) adjusts UCSCTL0:DCO by one. If the adjustment has to run the entire RSEL range (DCO=0-31) that takes about 32ms. [Ref User Guide (SLAU208Q) Sec 5.2.7, last paragraph. See also Sec 5.2.10]

    As a practical matter, the DCO settings on (DCO) restart are almost always just fine, and the FLL almost never has to run the entire RSEL range. An exception might be if you took your unit outside in the Winter during the time the FLL was disabled.

    I don't know of a way to tell that the FLL has settled. In some sense, it never "settles" since it's always watching and fine-tuning as needed.

    [Edit: Minor clarification]

  • Sorry Bruce, just one more clarification:

    What would be the bounds of the frequency error in the DCO clock at wakeup?

  • FYI

    My init_clocks routine calls the TI generated function config_mclk() which results in a 138ms fixed delay waiting for the FLL to settle:

    Init_clocks() -> config_mclk() -> Init_FLL_Settle()

    void Init_FLL_Settle(uint16_t fsystem, uint16_t ratio)

    {

       volatile uint16_t x = ratio * 32;

       Init_FLL(fsystem, ratio);

       while (x--){

           __delay_cycles(30);

       }

    }

  • The DCO error is described in the Data Sheet (SLAS655F) table in Sec 5.20.

    It quotes 0.1%/degreeC. So if you shifted temperature  85C->(-40C) while the DCO was off that would introduce an error of (85-(-40))*0.1=12.5%. An 8MHz DCO would then be running at 9MHz, and drift back to 8MHz over the next 32ms. Maybe such a shift could happen in a car engine compartment in Siberia over a half-hour.

    There's also a voltage component (1.9%/V), but I don't know of any application which routinely shifts power supply voltage that much.

    ---------------

    I'm not familiar with those functions. Do you know what the value of "ratio" is? The way it's coded, its apparent intent is to wait the maximum possible settling time. As I've suggested, this is almost certainly (much) longer than required, particularly if the CPU has only been asleep for say 100ms.

    Also, it's possible InitFLL sets an initial value in the DCO, in effect un-doing everything the FLL had been doing before. If so, that's counter-productive.

    But all I can do is state hypotheticals. You know better than I what your unit's intended environment is.

**Attention** This is a public forum