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.

MSP430F149: Internal Clock Frequency 5MHZ

Part Number: MSP430F149

Hello sir/madam,

MSP430F149: SPI Comunicate through pressure sensor

I have configured spi to communicate with pressure sensor ,so data we get uncompensated pressure(D1) and temperature(D2) through sensor,sensor need to configure by time of intilization had different delays to follow to get the data by accuracy rate ,in my program i followed 4096 osr for both pressure and temperature data,so the delay is (9ms) for each,overall 18ms approx ,so real problem is when i use internal clock frequency 5mhz approx,data i have get for D1 with time of 200 to 205 ms,it will take for each,so for both it will take 450ms approx, confirmed by the use of logic analyzer and oscilloscope,but these is uncompensated from sensor,then we need to do calculation for getting actual pressure and temperature data by follow of datasheet of sensor,overall time is above 500ms ,but it is too much time ,the same internal clock we have used prescalar to divide the clock frequency ,it works for acurate time of delay for each taking 9ms ,on both the clock scenario the data we taken from sensor ,but timing will differ,but for pressure sensor as per datasheet ,we can configure controller clock upto 20mhz is supportive ,we tested with atmega328p controller(atmel) upto 16mhz,is these any reason for frequency drift ,because voltage is maintained on 3.3v,what would be the reason ? 

 

image.png

 

 

  • Hi Rubesh,

    I am not sure I understand much of the scenario, but are you using interrupts or polling?

    Are you using a different MCU? the MSP430F149 is an 8MHz device.

    Here are the temperature drift characteristics of DCO from the datasheet:

    If you need a higher accuracy clock, I would recommend an external crystal or clock.

    Best,

    Owen

  • Hi,
    We are using Polling method for SPI communication to the sensor. Other peripherals are in interrupt methods. We would like to explain you the issue in a detailed way below. Please read the details below and get back to us. 

     External Crystal Not Available with the original product.
     The product we are replicating does not use an external crystal, we are constrained to the internal DCO. We would like to understand the best practices for maximizing DCO stability and communication reliability under this constraint.

    We are currently developing a product based on the MSP430F149 microcontroller and are encountering several issues related to the internal DCO (Digitally Controlled Oscillator) clock. We would appreciate your guidance on the following:

    1. DCO Configuration for ~5 MHz Operation
    As part of a reverse-engineering exercise on an existing product, we identified that the design relies on the MSP430F149's internal DCO clock, targeted at approximately 5 MHz. We have replicated this configuration in our development, but we are observing instability in the achieved frequency.

    2. SPI Communication Timing Errors Due to DCO Frequency Drift
    Due to inaccuracies in the DCO frequency, we are experiencing timing inconsistencies in SPI communication. Although communication is functionally operational, the clock frequency drift causes SPI transactions to take longer than expected at the target ~5 MHz. Even after adjusting the SPI prescaler to compensate, sensor data is not being fetched within the required time windows. Could you advise on the recommended approach to stabilize DCO frequency for reliable SPI operation?

    3. Timer Accuracy Degradation with Internal DCO
    We are observing timer tolerance issues when using the DCO as the clock source. The timer period deviates from expected values, which is impacting time-critical operations. Is there a recommended calibration or compensation method for improving timer accuracy when using the internal oscillator?

    4. Clock Instability After Wake from LPM3
    When the device wakes from Low Power Mode 3 (LPM3), the DCO does not appear to stabilize to the target frequency quickly enough before peripheral operations resume. This causes erratic behavior immediately after wakeup. What is the recommended procedure to ensure DCO stabilization before resuming normal operation after an LPM3 wake event?

  • Hi Rubesh,

    I am unsure how SPI is experiencing errors, as it is a synced protocol. How long are you polling for? Are you able to observe any data being sent on the SPI lines?

    As for improving accuracy, adding the ROSC resistor can help with temperature drift.

    Per the family user's guide, the DCO should be stable within 6us. I would  suggest adding a delay, if necessary.

    FYI:

    Best

    Owen