• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1468 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.

MSP430FR2111: DCO FLL lock time

Horst Eyermann89
Prodigy 150 points
Part Number: MSP430FR2111


We are considering to use a MSP430FR2111 device for our application.

In this application we need to:

  • sample a pin quickly (< 5ms) after power is applied.
  • communicate with a host System (at 9600 or 19200 baud); we are still open for the used baudrate not yet defined

When sampling the IO port, the operating frequncy does not have to be preceise, but for the USART communication we do need to match the Baudrate within about 4%.

The DCO with FLL would meet the requirement with 2%. But the FLL lock time is specified with 245ms typical, which is to long.

The device descriptor (TLV) contains a DCO Calibration value.

  1. what tolerance does the DCO have when using this value
  2. will the  FLL  lock faster when starting with the DCO calibration value? (how Long will it take?)

Any ideas are welcome

  • 0
    TI__Mastermind 39910 points

    Hi Horst

    Loading this value to the CSCTL0 register significantly reduces the FLL lock time when the MCU reboot or exits from a low-power mode.(Not the power on) .I want to make sure the sample a pin event is just on power on?

    If  the  the sample a pin even is happen reboot or exits from a low-power mode the DCO calibration can reduces the FLL lock time.This value will not effect the tolerance. The reduce time is depended on the different devices.Can you test it by your self with the oscilloscope?

    Best regards

    Gary

  • 0 in reply to Gary Gao
    Prodigy 150 points

    Hi Gary,

    thank you for the answer.

    In the application planned, we are not planning to use low power modes in the chip. So the only critical Timing after power on.

    I can measure the time it takes to lock the FLL when writing the CSCTL0 Register.

    But at best this would give me a typical Performance for the new lock time. If i want to know the Performance in production, i would Need to know more about the tolerances.

    I understand that there are four main contributors to DCO variations:

    * Supply voltage

    * temperature

    * device to device variation

    * unknown factors (drift, etc.)

    Is that correct?

    If writing to the CSCTL0 Register takes out the device to device specific Variation. Our supply voltage is fixed (at 3.3V)

    So temperature and the unknown factors remain. Is there some characteristics for These variations?

    Thanks,

    Horst

  • 0 in reply to Horst Eyermann89
    TI__Mastermind 39910 points

    Hi Horst

    We just offer the test data at Vcc is 3.0V.Here is the DCO FLL characteristics as below in the datasheet:

    So if you want high accuracy I suggest you use the XT1.

  • 0 in reply to Gary Gao
    Prodigy 150 points
    Hi Gary,

    thank you for posting the datasheet extract. I have two questions:

    1. As I understand it, the FLL lock time is faster when programming the CSCTL0 Register from the TLV descriptor. How fast?

    2. What accuracy can I expect from the DCO when programming it with the CSCTL0 Register, but not using the FLL?

    Thank you
    Horst
  • 0 in reply to Horst Eyermann89
    TI__Prodigy 485 points
    Hi Horst,

    It takes some clock cycles for FLL to get locked with the loaded CSCTL0 register. We don't have the accurate time for it in datasheet, but considering the DCO is running at 16MHz, the FLL lock time will be much less than 1ms which should be fine for your 5ms requirement. With FLL unlock, we will see big clock frequency variation which will cause the UART communication fail. In your case, FLL lock is must have.

    Best Regards,
    Darren

**Attention** This is a public forum