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

MSP430F149: USART0 Sometimes sends double bytes

Gordon Lee70
Prodigy 30 points
Part Number: MSP430F149

I have an application that uses 3-wire SPI (on USART 0) to talk to a CAN controller.  I recently uncovered an oscillator startup bug that was causing the MCLK to revert from XT2 (6 MHz) to DCO (2 MHz).  In this situation the USART clock is sourced by SMCLK (6 MHz). 

Without the bug USART operates normally.  When the oscillator startup bug occurs byte transfers are all doubled up.  (ie load the Tx buffer once, and two identical bytes are transferred).

I fixed the original bug and the problem goes away but I can re-create the SPI issue by manually changing the MCLK source to DCO.

What might cause the USART to send two bytes out, for each Tx load ?

  • 0
    TI__Genius 13215 points
    Hi Gordon,

    Could you share me the code you used?

    Wei,
    MSP Customer Applications,
  • 0 in reply to Wei.Jetim Zhao
    Prodigy 30 points

    Unfortunately I cannot share any code on the forum.

    I can share the following logic analyzer traces.  This transfer happens very early in the startup of my application.  The code executed up to the point this occurs is pretty linear and I'm fairly certain, identical in each case.  The only difference is the oscillator start up code switches MCLK to DCO in the second case but not the 1st.  You can kinda see the effect based on the amount of time between CS and the start of the transfer.

  • 0 in reply to Gordon Lee70
    Guru 46710 points

    Source of your problem most likely is unhappy with clock glitch, state machine of peripheral. I have no information about internals of peripheral, but It is highly unlikely that it has any clock sync logic to avoid "out of spec" or just rogue clock pulses while changing clock source.

    When you change anything about peripheral including it's clock, it is good idea to disable peripheral, make changes and reinitialize it after. Most probably then you will avoid double byte problem.

  • 0 in reply to Ilmars
    Prodigy 30 points

    Thanks ilmars and Wei for your responses,

    I'm not sure when  I'll be able to dig back into the details on this one, as fixing the oscillator startup issue solved the actual problem.

    My very rudimentary investigation seemed to suggest that the failure can occur even if I break execution after a reset, manually edit the clock source for MCLK and then proceed to SPI init and the 1st transfer shown in the traces.  In theory the oscillator is stable and clock sources are all settled before SPI is enabled|used.

    One question.  If the fail-safe mechanism reverts the clock-source to DCO, is this a one time event.  If the oscillator becomes stable will it switch back ?

    Thanks again

    Gord

  • 0 in reply to Gordon Lee70
    TI__Genius 13215 points
    hi Gordonr,

    The OFIFG will be set when crystal fault being detected. You should clear the OFIFG bit by software to switch the clock sourcing back to crystal. And make sure the OFIFG has already been cleared.

    1) Clear the OFIFG flag
    2) Wait at least 50 µs
    3) Test OFIFG, and repeat steps 1-4 until OFIFG remains cleared.

**Attention** This is a public forum