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.

MSP430FR2676: DCO frequency

Genius 9880 points
Part Number: MSP430FR2676


Hi Team,

My customer have questions regarding the DCO freq of the device, please see details below.

Three questions both concerning control of DCO frequency as per TI-supplied code example msp430fr267x_CS_08.c, in the Software_Trim() function:

1. in the following 'do' loop in the function (near the top):

do
        {
            CSCTL7 &= ~DCOFFG;                  // Clear DCO fault flag
        }while (CSCTL7 & DCOFFG);               // Test DCO fault flag

the DCOFFG flag is cleared and then immediately checked to see if it is clear or not.  How long does it take for this flag to become set again, once cleared?  The User Manual says DCOFFG is set if the DCO tap setting reaches 0 or 511, and the line immediately preceding the 'do' loop above sets DCO to 256, so won't it take some time for the tap to be automatically adjusted to 0 or 511 by the FLL, during which time DCOFFG will remain clear, causing immediate exit from the 'do' loop?  I can't see the point of this 'do' loop, please explain.

2. Following the 'do' loop above, there is:

__delay_cycles((unsigned int)3000 * MCLK_FREQ_MHZ);// Wait FLL lock status (FLLUNLOCK) to be stable
                                                           // Suggest to wait 24 cycles of divided FLL reference clock

Please can you explain how 24 cycles of divided FLL reference clock, times 1 (as this is the clock frequency in MHz), is equal to 3000?  I think I may be missing something here.  (The REFOCLK is nominally 32.768 kHz.)

3. How often does the FLL adjust the DCO tap under automatic control?  (I.e. is it n counts of REFOCLK, in which case what is n, or how to calculate it?

Thank you.

Regards,
May

  • Hi May,

    I will get back to you tomorrow.

    Evan

  • Hi Evan,

    Thank you.

    Looking forward for your response.

    Regards,
    May

  • Hi May,

    Thanks for your patience. Please make sure that the customer is following https://www.ti.com/lit/an/slaa992/slaa992.pdf there is example code given in this document as well.

    1. The point of the do-while loop is to make sure that the flag was successfully cleared. For example if you cleared DCOFFG and then it was immediately set again by hardware, the do-while loop will perform a readback and clear the flag again if necessary.

    2. The minimum what is 24 FLL reference clock cycles. In the example, it is simply waiting longer that 24 clock cycles. 

    3. Section 3.2.7 of the user guide says the that FLL mixes DCO taps over 32 clock cycles:

    Regards,

    Evan

  • Hi Evan,

    Thank you for the information, my customer have further questions regarding the number and need more information about it, please see details beow.

    You pointed out that 32 clock cycles are involved, however the section of the manual to which you referred states that this is for the Modulator. I wasn’t asking about the Modulator, I was asking about the FLL taking time to adjust the DCO tap. From my understanding, this can happen even if the Modulator is switched off, so I don’t think this has much to do with it.

    If the REFO clock at 32.768 kHz is used as input to the DCO, and a frequency of 1 MHz is required from the DCO using FLL (not Modulator), a DCO tap is first selected and applied. Then, the FLL works out whether the DCO tap is correct or not. If not, it changes the tap. My question was: how long does it take from setting the tap, to the FLL deciding whether it is the correct tap or not? (How to calculate it for different circumstances?)

    I would presume that the time is related to the REFO clock frequency in some way, e.g. a certain number of cycles of REFO, but it may be related to the DCO output clock cycles.

    Thank you.

    Regards,
    May

  • Hi May,

    Can you asked the customer why they need such detailed information? If they are worried about clock jitter, FLL is not a good architecture to begin with.

    Thanks,

    Evan

  • Hi Evan,

    Please see response from customer:

    My application will spend a lot of time in LPM3 (DCO is not running) and then, when event happens maybe months later, change to active mode and use DCO output immediately for accurate frequency generation at 1 MHz.

    But I understand that upon entering active mode, the previous DCO settings may not generate the accurate 1 MHz frequency, because conditions (particularly temperature) may have changed while in LPM3.

    Therefore, the FLL will have to settle upon the required frequency, during which time the 1 MHz may be a little off.  And, if it requires changing DCOFTRIM under software control, it will take longer.  All as described in Application Report SLAA992, DCO+FLL Applications Guide, which I have studied extensively and tried out some of the software routines it mentions In the code examples upon a LaunchPad.

    I cannot answer the question: how long will it take to produce an accurate 1 MHz clock, and wanted to know what this time might be.  It will affect my application.

    If the tap is set upon entry to active mode, to mid-point (256 decimal), and has to travel to one end to get a lock, or a fail-to-lock at that DCOFTRIM value, I wondered how long that would take.

    Apologies for the question, I am used to being in control of every event down to individual clock cycles of the MCU (not MSP430), and old habits die hard.  Or, at least, knowing what’s going on in each clock cycle.  Maybe a bit old-school.  I still want to know the effect on my application.

    Thanks you.

    Regards,
    May

  • Hi May,

    Thanks for asking the customer about this, however this level of cycle accuracy is probably going to be difficult to predict just based on the documentation. I would recommend the customer perform some tests to determine how long this process might take. Testing across different temperatures and voltages should give a good idea what the worst case is.

    Regards,

    Evan

**Attention** This is a public forum