How to minimize the waiting time for DCO settling ?

Why do you need to use a debugger to run an empty loop? If you single step through it, it will take even longer and you will get real tired too.

Hi old_cow_yellow.
Sorry for my insufficient explanation.

I used debugger as a simplified method to measure the actual execution time of the empty loop.

I set breakpoints at the previous and the next instruction of the empty loop.
And I measured the time between when the 1st breakpoint is hit then exited by pressing [F8] key
and when the next breakpoint is hit.

It is about 7 or 8 secnods.

Jens-Michael Gross said:

More complex is an algorithm that first disables modulation. The FLL will then start switchign between two adjacent DCOx settings around the desired frequency after 32 reference ticks at [most]

Ever tried this?  I think the FLL increments/decrements UCSCTL0 the same way whether modulation is enabled or not.  The difference when modulation is disabled is that the increment/decrement operations actually impact the DCO rate only every 32 increments/decrements.

Tall task trying to speed up the FLL settling.

Jeff

Jens-Michael Gross said:

n * 32 * 32 * (fMCLK / fFLLREFCLK ) = 9371648 (MCLK cycles)

This formula gives a naive fallacy calculation of the worst case delay (since you start with minimum DCO, your initial MCLK cycles are longer and therefore less are needed). And it seems wrong too. since fMCLK/fFLLRECLK is n, this forumly multiplies by n² where n would be correct.
Can you tell where you got it from  (document, revision and chapter/page/figure) ...

[/quote]

ITO probably misquoted from slau208k.pdf Section 5.2.7 on page 163. The last part of that Section says:

For a given DCO bias range setting, time must be allowed for the DCO to settle on the proper tap for
normal operation. (n × 32) fFLLREFCLK cycles are required between taps requiring a worst case of
(n × 32 × 32) fFLLREFCLK cycles for the DCO to settle. The value n is defined by the FLLREFDIV bits (n = 1,
2, 4, 8, 12, or 16)

It looks stupid but it is possible that the FLL in question actually works this way. There are 32*32=1024 possible settings and it takes n*fFLLREFCLK cycle to try each setting. Using binary chop, it should take 10*(n*fFLLREFCLK) to find the correct setting. But I do not know if the FLL in question works that way.

I think the following procedure might help. But then, it might not ;)

a) Disable the FLL, set up DIVM=5 (divide by 32); DCORSEL=6, DCO=16, MOD=0. (Start at the middle, not at one end or the other )

b) Do not disturb DCO, set up D=1, N+1=762, n=1, enable FLL.

c) Wait for the FLL to lock. (DCO locks to 1*762*0.32768/1=24.969 MHz)

d) Disable the FLL, do not disturb the DCO, change to D=16, N+1=572, n=12 as ITO's original post says. Enable FLL.

e) Wit for the FLL to lock again. (DCO locks to 16*571*0.032768/12=24.991 MHz as desired)

f) Change to DIVM=0 (divide by 1)

Thanks to all of you for replies.

On second thought, the root of my problem might be that I was obsessed by the fixed idea that
the source of MCLK must be switched to DCOCLK before FLL is enabled.

If MCLK and FLLREFCLK are the same when DCO parameters are initialized and FLL is enabled,
(n * 32 * 32) MCLK cycles could be enough for waiting DCO to be settled.

First, I would try this way in the day after next. (Till tomorrow, I am home for holiday.)

Jens-Michael Gross said:

Can you tell where you got it from  (document, revision and chapter/page/figure)

I think there is no formula exactly same with what I wrote.

I referred to the TI's sample code (MSP430F673X_UCS_4.asm) and that says,

; Description: This program demonstrates setting the internal DCO to run at
; 2.45MHz with auto-calibration by the FLL+ circuitry.It uses LFXT1 as FLL
; reference.
; ACLK = LFXT1 = 32768Hz, MCLK = SMCLK = DCO = (74+1) x REFO = 2457600Hz
[...]
; Worst-case settling time for the DCO when the DCO range bits have been
; changed is n x 32 x 32 x f_FLL_reference. See UCS chapter in 5xx UG
; for optimization.
; 32 x 32 x 2.45 MHz / 32,768 Hz = 76563 = MCLK cycles for DCO to settle

In this sample code, n = 1, and the period of FLLREFCLK can be up to
(fMCLK / fFLLREFCLK) times of the period of MCLK.

So I interpreted the formula,

32 x 32 x 2.45 MHz / 32,768 Hz [MCLK cycles]

as following.

n * 32 * 32 * (fMCLK / fFLLREFCLK ) [MCLK cycles]

Regards,

old_cow_yellow said:

and it takes n*fFLLREFCLK cycle to try each setting

old_cow_yellow said:

(n × 32) fFLLREFCLK cycles are required between taps requiring a worst case of (n × 32 × 32) fFLLREFCLK cycles for the DCO to settle.

Using FLLREFCLK/2 divider on a 32768Hz reference turns it into a 16384Hz reference. Which of course ticks only once per each two 32768Hz ticks.
Doing so would allow the FLL to settle at e.g. 3*16384=49152Hz with FLLn=3.

And yes, your proposed algorithm to do a quick adjust with full reference speed and then a finetune with divided reference should indeed speed up the process.