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.

Unstable system clock on MSP430F5438A

Other Parts Discussed in Thread: MSP430F5438A, TEST

customer said:

I think I’m seeing the clock speed up on the MSP430F5438A as much as 8%. This is affecting our serial communication using a UART and causing us to drop a byte. We are using a 32.768 kHz crystal and using the DCO with a multiplier of 512 to get it to 16.777216 MHz.  I was hoping you could suggest some causes for the clock rate changing. What can I look at?

The MSP430F5438A uses a Unified Clock System (UCS) module.

MSP430F543xA, MSP430F541xA Mixed Signal Microcontroller (Rev. B)  (PDF 1016 KB)  15 Oct 2010
Page 18 of 104

How have you sourced these clocks?

Auxiliary clock (ACLK)
    a 32-kHz watch crystal
    a high-frequency crystal
    the internal low-frequency oscillator (VLO)
    the trimmed low-frequency oscillator (REFO)
    or the internal digitally controlled oscillator DCO

Main clock (MCLK)
    a 32-kHz watch crystal
    a high-frequency crystal
    the internal low-frequency oscillator (VLO)
    the trimmed low-frequency oscillator (REFO)
    or the internal digitally controlled oscillator DCO

Sub-Main clock (SMCLK)
    a 32-kHz watch crystal
    a high-frequency crystal
    the internal low-frequency oscillator (VLO)
    the trimmed low-frequency oscillator (REFO)
    or the internal digitally controlled oscillator DCO

How have you set UCSSELx in the USCI_Ax Control Register 1 (UCAxCTL1)?

MSP430x5xx/MSP430x6xx Family User's Guide (Rev. J)
Page 767 of 906

  • An error of this is quite large. However, there are several things that can cause it.

    1) the 32768Hz crystal is attached but not properly initialized. The FLL is then sourced by REFO, which has some error.
    2) the FLL has not enough time to adjust the DCO properly
    3) a wrong RSEL setting is used, so maybe the FLL can adjust the DCO to the desired target frequency initially, but when the DCO begins to drift, it hits the limits of the RSEL setting and cannot adjust anymore.
    4) the desired frequency isn't available with one of the possible RSEL/DCO combinations and not even with modulation. Then the DCO will have a large jitter, jumping between two DCO settings all the time, and changing the jump pattern on every FLL adjustment step.

    Also, there are some known errata on the DCO/FLL combo:

    If the FLL adjusts the DCO between maximum modulation and the next higher DCO setting and no modulation, on some devices it switches to the next higher DCO but keeps current modulation, resulting in a much higher frequency, which is only slowly adjusted down again.

    If the FLL is active when the MSP enters an LPM where the DCO is deactivated and only wakes up for short periods of IST execution, the FLL won't properly weight between reference and DCO, adjusting the DCO further and further. If extended periods of LPM are only interrupted by short periods of ISR execution, an LPM should be used that disables the FLL. The LPM logic will then not enable the FLL when MCLK is re-enabled for ISR execution.

  • Isn't 8% close to the optimal difference between DCO taps? Maybe it's just the FLL regulation switching to a different tap.

    It should be noted that getting 16...MHz from the 32768 kHz crystal will probably be not the very best solution as it takes a rather long time until the next clock edge is there from the crystal making the FLL loop quite slow. Which is why you have to wait a lot of clock cycles to let the FLL settle:

    // Worst-case settling time for the DCO when the DCO range bits have been
    // changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx
    // UG for optimization.
    // 32*32*16.777216 MHz/32768Hz = 524288 = MCLK cycles for DCO to settle
     __delay_cycles(524288u);

    This should be done somewhere during the initialization. 

    Also maybe it's possible to let the FLL regulate the frequency once and then disable the logic (SCG0 bit) so that no tap switching occurs anymore. Regulation could be enabled with a given time after certain intervals to get rid of long term drift.

    Maybe using the clock rate detection feature of the USCI might be an option as well. 

  • Bernhard Weller said:
    // 32*32*16.777216 MHz/32768Hz = 524288 = MCLK cycles for DCO to settle

    That's a naive fallacy.
    It would be true if the DCO would run on the target frequency already, but then no adjustment cycles were necessary at all.
    Actually the DCO starts on the lowest tap, incrementing through all modulations until it switches between the two settings around the target point. How many MCLK cycles this will take depends on where it will settle, but even in worst case (31*32 steps, as there is no modulation on the highest step) it would be much less than what you calculated. Sicne during th efirst cycles, the resulting MCLK frequency is much lower.
    (On the 5438A, I think, it starts with 0.3 to 0.7MHz until it settles at 2MHz DCO = 1MHz MCLK)
    The only thing that can be said for sure is that after 30.27ms (=31*32 REFO counts), either the DCO has settled or the FLL has moved it to the highest tap, indicating that the target frequency cannot be reached with the current RSEL setting.
    This can be improved by first disablign modulation, and after 31 reference cycles (which one can count using a timer), modulation is enabled again. After additional 63 reference cycles, the DCO will have settled.
    Takes only 2.87ms.

  • Well, that's what TI teaches in code examples. I don't want to defend myself with that, the comment also states that it can be optimized but well I didn't bother with it (for me startup time is not an issue, and I know nothing about the implementation / requirements of the actual problem so being as lazy I am I also didn't bother optimizing it for someone else). My point simply was to indicate that there should be some delay implemented - and providing some worst case example might lead someone on the right track (reading more about the UCS probably what I should also do)

    Nice that you explained some optimizations - now I know about them and don't have to think about it. Even nicer if the code examples would show this as well (low power, huh?). But I guess this leads away from the original problem of this thread. 

  • Bernhard Weller said:
    Well, that's what TI teaches in code examples.

    Well, yes, TI code examples. Well.... ;)

    Bernhard Weller said:
    My point simply was to indicate that there should be some delay implemented - and providing some worst case example might lead someone on the right track

    Indeed. the FLL does no immediate adjust, nor does it provide a constant, jitter-free, exact output frequency. Only an average over time. And after some (relatively large) adjustment time too.
    It's relatively obvious if one bothers to read (and understand) the description of the FLL. If one doe snot simply start copying the code examples only.

    Bernhard Weller said:
    Even nicer if the code examples would show this as well

    What do you expect? as far as I can tell, the examples provide minimum basic funcitonality. No explanation - especially not if some advanced assumptions are used. Many of them are examples you can use as-is, or forget them.
    Personally, I think the code examples (and especially their 'documentation') are by far the weakest point in the whole MSP universe. Maybe not all of them, but the very most.
    Not well-explained enough to help a beginner to understand what's happening, and not sphisticated enough to be of any use for the more experienced ones. Personally, I never used one of them myself. Not even when I was starting with MSP. And I'm normally the type of coder who analyzes foreign code to 'get in' faster.

  • Hi All,

    I'm the customer that posed the question to Jason Work originally. I'd like to fill you in on the details. First, this only seems to be happening to a fraction of units. Out of a build of 100, we've had 4 exhibit this problem. On the affected units, this clock shift will happen regardless of how long the unit has been on so I don't think it's a FLL settling time issue. The clock seems to run at the correct frequency but it occasionally shifts. So for short bursts of UART traffic I don't usually see a problem, but for longer bursts it becomes more likely that the clock will shift and then the receiver will not be able to receive the data while the clock has shifted.

    In the firmware the UCS registers are set as follows:

        UCSCTL0 = 0x1F00;       /* DCO=4, MOD=0 */
        UCSCTL1 = 0x0040;       /* DCORSEL=4 */
        UCSCTL2 = 0x0200;       /* set the multiplier to x512 */
        UCSCTL3 = 0x0000;       /* FLL clk = XT1CLK, DIV1 */
        UCSCTL4 = 0x0033;       /* set the clock sources: ACLK=XT1CLK, SMCLK=DCOCLK, MCLK=DCOCLK */
        UCSCTL5 = 0x0000;       /* clock source dividers: ACLK/1, SMCLK/1, MCLK/1 */
        UCSCTL6 = 0x0000;       /* turn off XT2, XT1 is in low frequency mode, 2pF caps on inputs */
        UCSCTL8 = 0x000F;        /* enable clock requests */


    As shown I have DCORSEL set to 4. I noticed that on the 5438a device specific datasheet there is DCO frequency table as follows:

     

    PARAMETER

    TEST CONDITIONS

    MIN

    MAX

    UNIT

    fDCO(0,0)

    DCO frequency (0, 0)

    DCORSELx = 0, DCOx = 0, MODx = 0

    0.07

    0.20

    MHz

    fDCO(0,31)

    DCO frequency (0, 31)

    DCORSELx = 0, DCOx = 31, MODx = 0

    0.70

    1.70

    MHz

    fDCO(1,0)

    DCO frequency (1, 0)

    DCORSELx = 1, DCOx = 0, MODx = 0

    0.15

    0.36

    MHz

    fDCO(1,31)

    DCO frequency (1, 31)

    DCORSELx = 1, DCOx = 31, MODx = 0

    1.47

    3.45

    MHz

    fDCO(2,0)

    DCO frequency (2, 0)

    DCORSELx = 2, DCOx = 0, MODx = 0

    0.32

    0.75

    MHz

    fDCO(2,31)

    DCO frequency (2, 31)

    DCORSELx = 2, DCOx = 31, MODx = 0

    3.17

    7.38

    MHz

    fDCO(3,0)

    DCO frequency (3, 0)

    DCORSELx = 3, DCOx = 0, MODx = 0

    0.64

    1.51

    MHz

    fDCO(3,31)

    DCO frequency (3, 31)

    DCORSELx = 3, DCOx = 31, MODx = 0

    6.07

    14.0

    MHz

    fDCO(4,0)

    DCO frequency (4, 0)

    DCORSELx = 4, DCOx = 0, MODx = 0

    1.3

    3.2

    MHz

    fDCO(4,31)

    DCO frequency (4, 31)

    DCORSELx = 4, DCOx = 31, MODx = 0

    12.3

    28.2

    MHz

    fDCO(5,0)

    DCO frequency (5, 0)

    DCORSELx = 5, DCOx = 0, MODx = 0

    2.5

    6.0

    MHz

    fDCO(5,31)

    DCO frequency (5, 31)

    DCORSELx = 5, DCOx = 31, MODx = 0

    23.7

    54.1

    MHz

    fDCO(6,0)

    DCO frequency (6, 0)

    DCORSELx = 6, DCOx = 0, MODx = 0

    4.6

    10.7

    MHz

    fDCO(6,31)

    DCO frequency (6, 31)

    DCORSELx = 6, DCOx = 31, MODx = 0

    39.0

    88.0

    MHz

    fDCO(7,0)

    DCO frequency (7, 0)

    DCORSELx = 7, DCOx = 0, MODx = 0

    8.5

    19.6

    MHz

    fDCO(7,31)

    DCO frequency (7, 31)

    DCORSELx = 7, DCOx = 31, MODx = 0

    60

    135

    MHz

    Please correct me if I`m interpreting this table incorrectly but I read this as saying that of DCORSEL is set to 4 then the maximum DCO frequency I can reliably achieve is 12.3 MHz (DCORSELx = 4, DCOx = 31) which is less than the 16.77 MHz I`m targetting. Because the nominal frequency at DCORSELx = 4, DCOx = 31 (12.3+28.2=20.25 MHz) is higher than my target frequency it seems I'm OK most of the time, which is why only a small fraction of our build is affected.

    fDCO(0,0) DCO frequency (0, 0) DCORSELx = 0, DCOx = 0, MODx = 0 0.07 0.20 MHz
    fDCO(0,31) DCO frequency (0, 31) DCORSELx = 0, DCOx = 31, MODx = 0 0.70 1.70 MHz
    fDCO(1,0) DCO frequency (1, 0) DCORSELx = 1, DCOx = 0, MODx = 0 0.15 0.36 MHz
    fDCO(1,31) DCO frequency (1, 31) DCORSELx = 1, DCOx = 31, MODx = 0 1.47 3.45 MHz
    fDCO(2,0) DCO frequency (2, 0) DCORSELx = 2, DCOx = 0, MODx = 0 0.32 0.75 MHz
    fDCO(2,31) DCO frequency (2, 31) DCORSELx = 2, DCOx = 31, MODx = 0 3.17 7.38 MHz
    fDCO(3,0) DCO frequency (3, 0) DCORSELx = 3, DCOx = 0, MODx = 0 0.64 1.51 MHz
    fDCO(3,31) DCO frequency (3, 31) DCORSELx = 3, DCOx = 31, MODx = 0 6.07 14.0 MHz
    fDCO(4,0) DCO frequency (4, 0) DCORSELx = 4, DCOx = 0, MODx = 0 1.3 3.2 MHz
    fDCO(4,31) DCO frequency (4, 31) DCORSELx = 4, DCOx = 31, MODx = 0 12.3 28.2 MHz
    fDCO(5,0) DCO frequency (5, 0) DCORSELx = 5, DCOx = 0, MODx = 0 2.5 6.0 MHz
    fDCO(5,31) DCO frequency (5, 31) DCORSELx = 5, DCOx = 31, MODx = 0 23.7 54.1 MHz
    fDCO(6,0) DCO frequency (6, 0) DCORSELx = 6, DCOx = 0, MODx = 0 4.6 10.7 MHz
    fDCO(6,31) DCO frequency (6, 31) DCORSELx = 6, DCOx = 31, MODx = 0 39.0 88.0 MHz
    fDCO(7,0) DCO frequency (7, 0) DCORSELx = 7, DCOx = 0, MODx = 0 8.5 19.6 MHz
    fDCO(7,31) DCO frequency (7, 31) DCORSELx = 7, DCOx = 31, MODx = 0 60 135 MHz
  • Mark Blackburn said:
    Please correct me if I`m interpreting this table incorrectly

    You do - a little bit. The frequency range on DCORSEL=4 can range from 1.3MHz (DCOx=0) to 28.2MHz(DCOx=31) but the range may be as narrow as 3.2 to 12.3MHz.
    If you want 16MHz target frequency, you'll be better off with DCORSEL=5, which can range from 2.5 to 54.1MHz, but will for sure cover the range from 6 to 23.7MHz.

    So DCORSEL_4 may work, DCORSEL_5 will work, as well as DCORSEL_6. DCORSEL_7, however, may too be okay, but also might not.

    If you use DCORSEL_4 for 16MHz, this might be the reason for the failure you observe. I'd expect some devices even further off than just 8%.

    You can check on those devices which fail, whether DCOx is DCO_31 (the FLL has latched-up) and DCOFFG is set again after some time. (~30ms)

    However, the othe rerratum I mentioned can still apply. I thappens when the target frequency is between DCO_x/MOD_31 and DCO_x+1/MOD0. The FLL may then erroneously switch to DCO_x+1/MOD_31, causing the DCO to have a large overswing that is only slowly adjusted down again.

  • Thanks Jens-Michael,

    I've tried setting DCORSEL_5 and my problem seems to have vanished on one of my problem units. I was suspecting that I might need to increase DCORSELx, but I'm glad I got some confirmation. Hopefully I'll be able to apply this change to all our units without any problems.

    Jens-Michael Gross said:
    I'd expect some devices even further off than just 8%.

    That may very well be the case. Maybe those units are in our pile of bricks that I haven't had a chance to troubleshoot yet.

    Jens-Michael Gross said:
    However, the othe rerratum I mentioned can still apply. I thappens when the target frequency is between DCO_x/MOD_31 and DCO_x+1/MOD0. The FLL may then erroneously switch to DCO_x+1/MOD_31, causing the DCO to have a large overswing that is only slowly adjusted down again.

    I do in fact have the FLL enabled. I just wonder why the FLL wouldn't cause the DCO_x to settle down at DCO_5 eventually. I'm also now concerned that the FLL may sometimes switch the DCO_x to DCO_4 and I'd have the same problem until the next reset. Maybe I'd be best to disable the FLL during communication and only enable for short periods to correct drift between communication events.

    Thanks for pointing me at this errata. The errata (UCS10) states:

    "The erroneous behavior is seen when the FLL is tracking close to a DCO step boundary and the MOD counter is expected to rollover but, instead, the DCO bits increment and the MOD bits decrement. This causes the DCO to shift by up to 12% and remain at an increased frequency until approximately 15 REFCLK cycles have elapsed. The frequency reverts to the expected value immediately afterward."

    That sounds a lot like what I'm experiencing.

  • Mark Blackburn said:

    The erratum (UCS10) . . . sounds a lot like what I'm experiencing.

    Let's take a look.

    Nishant Garg said:

    To verify if this error is caused by UCS10, try to observe what happens to the DCO and MOD bits in the system. If the bits are changing as per the description of UCS10 in the errata, then the jitter can likely be a corresponding result, and the described workarounds can be implemented. If the DCO and MOD bits are not behaving as per UCS10, the source of the error could be something else.

    Please confirm if you have selected the Sub-Main clock SMCLK (and consequently the internal digitally controlled oscillator DCO) as the USCI clock source.

  • Mark Blackburn said:
    I just wonder why the FLL wouldn't cause the DCO_x to settle down at DCO_5 eventually

    The FLL only adjusts the DCOx/MODx settings (as tehy are in one register and you can jsut increment/decrement this register to get to the next 'step'.
    Since RSELx settigns do overlap, an automatic handling wouldn't be the most effective way to adjust the DCO :)

    Since the coder knows the target, it's up to him to pick the best RSEL setting.

    However, it might be a 'more sophisticated' way to settle the DCO if you supervise teh FLL. Check whether the FLL is actually starting to lower the DCOx/MODx settings again (indicating that the target frequency has been reached) and then check whether it selltes on MODx=31. If so, switch to the other possible RSEL setting (there are almost always two), to avoid the FLL erratum. It's unlikely that on both RSEL settings the target frequency is around MODx=31.

    I wonder whether the DCO erratum always applies if MODx should rollover. If so, the FLL adjustment would also make 'jumps' when trying to initially find the target frequency - leading to a faster adjustment, but also always to an overshoot at the end. This should be researched further.
    Unfortunately, the errata sheet is not detailed enough about this.

    The problem with temporarily disablign the FLL is that after enabling it, there may be a longe rperiod of adjustment need, and probably the first adjustment goes into the wrong direction (caused by an incomplete adjustment cycle).

    The best solution for a stable and exact frequency is still acrystal. At the expense of ~300µA additional current consumption (4MHz, more for higher frequencies)

  • Hi Mark and Jason,

    Just wanted to make sure that you had seen the app note UCS10 Guidance that describes the errata in more detail, it's potential application effects (for example on UART like in this case), and then puts forth a few different workarounds for dealing with it (these include operating your UART at a lower frequency to absorb the jump, disabling the FLL and doing a periodic trim, or implementing a software FLL). It includes some example code for implementing the periodic FLL trim and the software FLL.  Hope this helps.

    Regards,

    Katie

  • Thanks again for a valuable link, Katie.

    It's difficult to keep track of new app notes and/or new releases of datasheets etc.

  • Jens-Michael Gross said:

    It's difficult to keep track of new app notes and/or new releases of datasheets etc.

    I find this service helpful to notify me of changes to device documentation.

  • I know this service. The problem with this is that you get spammed with notifications when you watch more than a few. My MSP folder currently contains >300 different datasheets and appnotes. And that's just the MSP.
    I wonder how many mails I'd get if a new version of a users guide is available?

    Also, I must admit that I stay away from those 'notify me' buttons. It#s one here, one there, and at the end I spend 25hrs/day scanning my mail.
    I prefer searching for information when I need it (for my own projects, not just for reference in the forum). Or if it happens to come across, like the link Katie posted.
    Of course an FTP server with all the documents and 'telling' names would be great. Just what I built on my HD.

  • Or a link in the errata to further documentation (if there is any) would also be quite nice (yeah I know the errata has to be changed then if some new documentation is available, but it's quite hard to find the right application note out of the many - and it's not a very common place to look for errata related stuff)

  • I latched onto the possibility of getting a stable clock faster and tried this out.

    Jens-Michael Gross said:
    // 32*32*16.777216 MHz/32768Hz = 524288 = MCLK cycles for DCO to settle

    That's a naive fallacy.
    It would be true if the DCO would run on the target frequency already, but then no adjustment cycles were necessary at all.
    Actually the DCO starts on the lowest tap, incrementing through all modulations until it switches between the two settings around the target point.[/quote]

    I believe it does this only if UCSCTL0 is cleared during the FLL configuration; otherwise it would start wherever it was left set, right?  It doesn't automatically restart at the lowest tap as far as I can tell.

    Jens-Michael Gross said:
    How many MCLK cycles this will take depends on where it will settle, but even in worst case (31*32 steps, as there is no modulation on the highest step) it would be much less than what you calculated. Sicne during th efirst cycles, the resulting MCLK frequency is much lower.
    (On the 5438A, I think, it starts with 0.3 to 0.7MHz until it settles at 2MHz DCO = 1MHz MCLK)
    The only thing that can be said for sure is that after 30.27ms (=31*32 REFO counts), either the DCO has settled or the FLL has moved it to the highest tap, indicating that the target frequency cannot be reached with the current RSEL setting.

    My experimentation confirms this, or at least that after 31*32 REFCLK cycles DCO and MOD values are very close to what they are on later reads of UCSCTL1.

    Jens-Michael Gross said:
    This can be improved by first disablign modulation, and after 31 reference cycles (which one can count using a timer), modulation is enabled again. After additional 63 reference cycles, the DCO will have settled.
    Takes only 2.87ms.

    I have not been able to confirm this. I read what you wrote as saying that while modulation is disabled the FLL adjusts only the DCO taps but not the modulation, and after waiting for the right one to be selected (31 cycles), re-enabling modulation does the fine tuning by adjusting modulation within two adjacent taps.  Is that what you meant?

    Experimentation, and section 5.2.9 of the user's guide, both suggest that all DISMOD does is disable the feedback from the DCO and MOD values.  UCSCTL1 appears to continue to be updated (incrementing MOD, overflowing into DCO) even with DISMOD disabled, and will only reach its stable state after about 31*32 REFCLK cycles.

    Specifically, when I disable FLL, configure it with:

      UCSCTL0 = 0;
      UCSCTL1 = DISMOD | ctl1;
      UCSCTL2 = ctl2;
      UCSCTL3 = SELREF__XT1CLK | FLLREFDIV_0;

    then re-enable FLL, I uniformly get the following sort of readings from UCSCTL0 immediately after re-enabling FLL (initial), 32 REFCLK cycles later (32), 63 REFCLK cycles after that (32+63), and 31*32 REFCLK cycles (fnl) after FLL enabled.

    CTL0 initial DCO 0 MOD 1
    CTL0 32 DCO 1 MOD 22
    CTL0 32+63 DCO 4 MOD 26
    CTL0 fnl DCO 28 MOD 25

    These values are roughly the same no matter when in this process DISMOD is cleared, or if it's never set at all.  Checks of UCSCTL0 after the system has been running for a few seconds show configuration very near fnl.  In this case the target frequency was 10^6 Hz with RSEL1 on an MSP430F5438A (FLLN=29, FLLD=/2).

    Tests were performed with XT1 stable, UCS using XT1 as REFCLK and driving ACLK from XT1, and delays by looping on TA1 clocked by ACLK until the specified count passed.

    Maybe I'm doing something wrong, but it does look like the full n*31*32 REFCLK cycles is required for stabilization in the worst case.

    Since MCLK derives from REFCLK even while it's changing, the original delay in cycles seems like a correct worst-case approach if you can't steal a timer for this.

    Contrary to the comment in the example code, I was unable to find any text in the user's guide describing an optimization to this delay, though I'd still like to know one.

  • Peter,

    Thanks for a well considered and thorough post.

    For what it's worth, I don't see anything missing in your findings.  The prospect that the FLL might operate differently with DISMOD set is hopeful and not substantiated by the documentation.

    Mark,

    I originally discovered and reported the bug that is now UCS10 three years ago.  As a work around, I decided to use the FLL periodically and keep it off most of the time.  The MCU architecture supports this approach very nicely because the hardware never automatically clears SCG0, not even when waking from LPM.

    In that workaround, the real trick is turning off the FLL safely after using it to trim the DCO.  The problem is that you might turn off the FLL after it has just made the very error described in UCS10.  As luck would have it, most solutions to that problem also allow you to turn off the FLL way before n*31*32 REFCLK cycles because you are watching the FLL operation.  You can see when it is settled.

    Jeff

  • Peter Bigot said:
    I believe it does this only if UCSCTL0 is cleared during the FLL configuration; otherwise it would start wherever it was left set, right?  It doesn't automatically restart at the lowest tap as far as I can tell.

    Indeed. But 0 is the PUC default (so it starts on 0 after a reset of any kind, watchdog, violations, whatever).
    If you indeed reconfigure the DCO/FLL after some operation, the starting conditions are different. It is, however, recommended to set the DCO back to 0 before you raise RSEL.
    Peter Bigot said:
    My experimentation confirms this, or at least that after 31*32 REFCLK cycles DCO and MOD values are very close to what they are on later reads of UCSCTL1.
    Well, after 31*32 REFCLK cycles, teh FLL has either stepped through all possible settings or is already trackign around the final setting.
    However, assuming the number of MCLK cycles to wait for settlign to be 31*32*target frequency/32768 cycles is wrong, as the adjustment either starts with a lower frequency (therefore less MCLK cycles), already has the target frequency (no MCLK cycles needed for settling) or at a higher frequency (and will probably never settle, if starting with DCOx=0 and it is already too high)

    A safe way to halve the worst-case settling time is to start with DCOx=16. But only if you can be sure that this won't be already above the allowed operating range (or you add an MCLK divider to ensure this until settled).

    Peter Bigot said:
    Experimentation, and section 5.2.9 of the user's guide, both suggest that all DISMOD does is disable the feedback from the DCO and MOD values.

    Not exactly. The users guide only states that it will disable the modulation of the DCO tap between DCOx and DCOx+1. It does not talk about the FLL or how a disabled modulation is handled by the FLL.
    IMHO it's stupid to do 32 steps through MODx if modulation is disabled. And I think I got a different information two years ago. But as I wrote in a different thread, I prefer facts over fiction, and your experiments are facts.

    The only way to shorten settling time then would be to do successive approximation. Set DCOx=16 and let the FLL work two reference cycles. Then check in which direction the FLL has adjusted. Now set DCO to 8 or 24 and wait again etc. This way, you should get it settled in 20 cycles = 610µs (if this justifies the code effort).
    However, I'm making the assumption here that the FLL will be able to determine the correct adjustment direction after one possibly wrong 'partial' cycle. it might be necessary to disable and enable it to 'reset' a possible internal counter state.

    Peter Bigot said:
    it does look like the full n*31*32 REFCLK

    n? You mean FLLREFDIV__n?
    Peter Bigot said:
    Since MCLK derives from REFCLK even while it's changing
    The original calculation was based on MCLK sourced by DCO (the PUC default)
    Sure, if you source MCLK by REFCLK, then after at most  31*32 MCLK cycles the FLL has settled or latched. Which is still ~30ms :)
    For MCLK sourced by DCO, I think the worst case in MCLK/DCO cycles is rather half of the original calculation. (requiring some logarithmic calculations for a more precise - and still not much more useful - result.)

**Attention** This is a public forum