• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 68 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5989: Calibration procedure on the MSP430FR5989IPM RTC_C

Guillaume Henri
Expert 3806 points
Part Number: MSP430FR5989

 Hi MSP430 champs,

 Could you help on those questions please ?

 In this case the 512Hz output is used to calibrate and verify the RTC calibration on MSP430FR5989IPM RTC_C - the questions here below are about the compensation method of the offset calibration referring to “29.2.7.1.1 Calibration mechanism” MSP430FR59xx user’s guide :

Q1/ Is the 512Hz frequency modified depending on the RTCOCALx ?

Q2/ What is the 512Hz frequency stability ? Several measures have been performed and one can see an important frequency variation (+/- 10ppm)

Q3/ When applying a compensation of 0, +30 and then -30, no difference has been observed on the measured 512Hz frequency. How could this be explained ?

 

Thank you!

Best regards,

Guillaume

  • 0
    TI__Mastermind 49692 points

    Hello,

    Guillaume Henri said:
    Q1/ Is the 512Hz frequency modified depending on the RTCOCALx ?

    Correct. See Section 29.2.7.1.1 in the user guide for more details.

    Guillaume Henri said:
    Q2/ What is the 512Hz frequency stability ? Several measures have been performed and one can see an important frequency variation (+/- 10ppm)

    The calibration mechanism features a resolution down to 1-ppm. Keep in mind that load capacitance and temperature changes influence frequency variation too. For more details about crystals, refer to the MSP430 32-kHz Crystal Oscillators app note.

    Guillaume Henri said:
    Q3/ When applying a compensation of 0, +30 and then -30, no difference has been observed on the measured 512Hz frequency. How could this be explained ?

    Both RTCOCAL_L and RTCOCAL_H registers are protected and require RTC_C to be unlocked before writing into these registers. RTCOCAL should only be written when RTCHOLD = 1.

**Attention** This is a public forum