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.

MSP430FR2032 | FLL settling when referenced to REFO

Other Parts Discussed in Thread: MSP430FR2032, MSP430FR2033

How long does it take for DCO to settle at 16MHz, referenced to REFO, when set to this configuration shortly following BOR?  (w/ MSP430FR2032 & MSP430FR2033)

 

In the datasheet I see 120ms listed in table 5-4, with XT1 as reference.  However I don’t see a spec listed with REFO as reference. 

 

Driverlib function CS_initFLLSettle() includes a fixed delay of 52ms, which appears to be insufficient. 

 

Please clarify the best practices for using the FLL to set the DCO when using REFO after a BOR.

 

Thanks.


  • Hello Antennahead,

    What we have in the datasheet is all the information we can provide. As it stands, FLL settle time is only spec'd in regards to using an Xtal on XT1. DriverLib examples are also built on the assumption and do not test for every possible case. That being said, I would treat the REFO as a bad Xtal and check for settling time in similar matter. Of course with REFO you do not have the XT1OFFG to check. You can set FLLWAREN to generate an interrupt when the FLL is not locked. This allows the FLL to set the OFIFG if FLLUNLOCKHIS is not "00". this way you could do a similar loop to XTAL stabilization for waiting for the FLL settle.

    //Pseudo Code
    while(OFIFG)
    {
      clear OFIFG
      wait some delay
    }

    Please keep in mind the REFO is not that accurate and can vary wildly due to temperature. REFO can vary based on process (chip to chip variance). This may cause FLL settling times to vary.

  • The main question here is how long does it take for the FLL to settle using REFO from a BOR or cold boot?

    I understand the data sheet doesn't clearly spec this; however, can you please make an educated guess here?

    This time frame is needed to properly set a timeout delay in case there is a problem- so that the device can indicate an error if the FLL doesn't lock with a certain time frame.

    Thanks, Best, Steve

  • Since they are using the FLL to trim the DCO to 16 MHz, I suggested to them that they seed the DCO with the 16 MHz calibration value found in the device descriptor.

    The sped up the FLL lock time by a factor of 20.

  • Steve,

    That sounds like a great idea. Any issues from customer side on this approach?
  • No, so far they are thrilled with the improvement. But they continue to test.

**Attention** This is a public forum