• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1014 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DCO – Delay or not… that is the question?

Steve Hinshaw
Intellectual 515 points
Other Parts Discussed in Thread: MSP430F5529

The MSP430x5xx Family User’s Manual states…

 

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).

 

Several of the examples in ‘F552x_C_Code_Examples’ include the delay…

 

  __bic_SR_register(SCG0);                  // Enable the FLL control loop

 

  // 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 x 32 x 2.45 MHz / 32,768 Hz = 76563 = MCLK cycles for DCO to settle

  __delay_cycles(76563);

 

  // Loop until XT1,XT2 & DCO fault flag is cleared

  do

  {

    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);

                                                               // Clear XT2,XT1,DCO fault flags

    SFRIFG1 &= ~OFIFG;                      // Clear fault flags

  }while (SFRIFG1&OFIFG);                  // Test oscillator fault flag

 

While the ‘void Init_FLL(const unsigned int fsystem, const unsigned int ratio)’ function in ‘hal_USC.C’ does not.

 

Delay or not?

 

Thanks,

Steve

  • 0
    TI__Mastermind 26380 points

    Steve,

    Could you update us on where you found this code being used?

    The delay is definitely required for the FLL to settle.

    The hal_ucs.c file provides 2 options:

    1) you can use init_fll and introduce your own delay in the application code - for e.g. using a timer

    OR

    2) you can use the function init_FLL_settle() that includes the delay for you.

    void Init_FLL_Settle(uint16_t fsystem, uint16_t ratio)
    {
      volatile uint16_t x = ratio * 32;      
     
      Init_FLL(fsystem, ratio);
     
      while(ratio--)
      {
       __delay_cycles(30);
      }

    }

    If any examples on the TI webpage are not following these guidelines do let us know and we can correct it.

    I have also uploaded the latest version of hal_ucs.c and hal_ucs.h so you can take a look at the code.

    Regards,

    Priya

    HAL.zip
  • 0 in reply to Priya Thanigai
    Intellectual 515 points

    The hal_usc.c file that you uploaded is different than what's included in the 'MSP430 USB CDC+HID API Stacks (Rev. A)' (AKA slac285a.zip) that's on the MSP430F5529 webpage.

    It appears that all of these examples call Init_FLL(fsystem, ratio) without a delay following.

    Steve

     

     

  • 0 in reply to Steve Hinshaw
    Intellectual 515 points

    I've attempted to drop your updated hal_usc files into my project (which started life as one of the USB examples), but it won't build because of some missing include files referenced from your updated hal_usc files.

    The updated hal_usc.c has an include of #include "msp430.h" which the compiler can't find and the hal_usc.h has an include of #include "hal_macros.h" which is also missing in action.

    Steve

  • 0 in reply to Steve Hinshaw
    TI__Mastermind 26380 points

    Steve,

    Sorry, that was my mistake.  I did not know that you were referring to the USB stacks.

    The files that I sent you are a part of the revised hardware abstraction library and cannot be used with the stacks as-is today.

     We do plan on modifying the USB stacks and other examples that use the HAL to include the FLL delay.

    A short term solution for your problem would be to simply add the intrinsic __delay_cycles(x) after the Init_FLL function is called.

    Alternatively, you can use the timer to provide this delay while waiting in LPM0.

    Hope this helps.

    Regards,

    Priya

  • 0 in reply to Priya Thanigai
    Guru 227245 points

    The FLL will (at this given destination frequency) adjust the DCO settings every 75 MCLK cycles. This is an average value, only true if the DCO is already running at desired frequency.
    Also, the FLL needs up to 32x32 adjustments if DCO starts at lowest tap and needs to be set to highest tap. This gives the 76562 MCLK cycles for the delay.

    But these 'worst cases' are excluding each other. If the DCO starts at lowest tap, the next adjustment is not 75 but just a few MCLK cycles later. And if the DCO is already near the destination tap, then an adjustment takes 75 cycles, but there are much less than 32x32 adjustments necessary. Also, if the destination frequency is in the middle of the DCO frequency range (which it is), then also less than 32x32 adjustments are necessary. And last but not least does the DCO not start at the lowest point.

    If you initially pick a DCO tap that's somewhere near the desired frequency, the FLL will settle the DCO in a few 100 cycles. You can read the settled values and use them as starting point.

    And even in worst case, 76k cycles at 2.45MHz are just 30ms. In very most cases you can just continue and these 30 ms will pass sooner or later before anything important takes place that requires a precision timing.

**Attention** This is a public forum