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.

error in current 5xx/6xx DCO examples

The F5xx_F6xx_Core_Lib/HAL_UCS.c with the most recent 5529 User Experience, and section 1.4.3 of the 5xx/6xx User Guide (slau208j), both have incorrect code that is intended to disable the FLL prior to configuring UCS registers, but in fact clears SCG0 which does not have that effect; e.g.:

  // Save actual state of FLL loop control, then disable it. This is needed to
  // prevent the FLL from acting as we are making fundamental modifications to
  // the clock setup.
  uint16_t srRegisterState = __get_SR_register() & SCG0;
  __bic_SR_register(SCG0);  

The latest 54xx examples in slac166q have the correct sequence (given certain assumptions about the starting condition):

  __bis_SR_register(SCG0);                  // Disable the FLL control loop
  UCSCTL0 = 0x0000;                         // Set lowest possible DCOx, MODx
  UCSCTL1 = DCORSEL_5;                      // Select DCO range 16MHz operation
  UCSCTL2 = FLLD_1 + 244;                   // Set DCO Multiplier for 8MHz
                                            // (N + 1) * FLLRef = Fdco
                                            // (244 + 1) * 32768 = 8MHz
                                            // Set FLL Div = fDCOCLK/2
  __bic_SR_register(SCG0);                  // Enable the FLL control loop
  • You're right.

    In the HAL, this mistake likely doesn't make a noticeable difference (especially if the FLL isn't "enabled" teh wrong way after the configuration change) in most cases.
    These 'most cases' seem to have included the testign of the library. :(

    I think, disablign and enablign the FLL serves a second putpose. Beside the fact that manual changes of the DCO will 'disturb' the regulating loop (which isn't such a big problem, as drift of the DCO will also have similar effects, and you'll have to wait for the FLL to settle anyway, so a short regulation in the wrong direction won't hurt), there is the FLL erratum on some MSPs which lets the FLL ignore some configuration changes if more than one FLL-related register is changed within the same reference cycle. I guess, switching the FLL off and on will ensure it obeys the new configuration.

**Attention** This is a public forum