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.

  • Resolved

MSP430 USCI-Uart Silicon Problem?

Guru 15690 points

Replies: 13

Views: 1678

We have been using the MSP430F5515 in production and have begun to run into serious problems with the USCI in UART mode. The UART bit time errors seem to vary significantly more than they should. Can a TI employee verify that there is not a silicon problem with the UART?

Here are our parameters:

UART BRCLK is sourced from MCLK which is derived from a 32.768khz crystal. Crystal frequency has been measure at 32768Hz exactly.

MCLK is initialized to 16MHz has been measured at 15.997MHz.

UART buad rate is set to 230400 using UCOS16=0 to minimize the calculated potential bit errors. From the Family User Guide (SLAU208M)

As a test we send a series of sixteen 0xAA bytes from the MSP to a DSP (TMS320C5515). The results are show below:

The test shows two consecutive 8-bit words from our test sequence.

The first word (Unit 1, Word Sample 1) is sent and received correctly. The cumulative bit time error is -.21% which is acceptable.

The second word (Unit 1, Word Sample 2) is sent as a 0x95 instead of 0x55 since the cumulative bit time is 5.59% too short. Below is a screen shot of the two consecutive words.

It is clear from our tests that the bit times generated by the MSP430 are inaccurate and vary from word to word. This "short word" happen sporadically and at with varying recurrence of different chips.

Can someone from TI please investigate this issue and get back to me asap?

Or if someone can see something we are doing wrong, please let us know.

 

Thx,

MikeH

 

  • The DCO has jitter. At such high baud rates, the clock should come directly from a crystal.
  • Guru 15690 points

    In reply to Clemens Ladisch:

    Clemens,

    Thanks for the reply, but isn't this what you mean?

    UART BRCLK is sourced from MCLK which is derived from a 32.768khz crystal. Crystal frequency has been measure at 32768Hz exactly.

    Thx,

    MikeH

     

  • In reply to MikeH:

    No, that is not what Clemens is saying. He is suggesting that your MCLK come from a 16Mhz crystal, like on XT2 pins.

    To his point, have you analyzed the accuracy of the 3278 crystal? Did you measure it with a good frequency counter or just use the (less accurate) scope measurement tools? Have you done an analysis of the crystal accuracy all the way through the DCO to see what the timing variance can be on MCLK?

    ~Brian


    Help make the forums a better place. Please click "Verify Answer" when someone helps solve your issue.

    Please use the  button to insert code so that it is readable.

  • In reply to Brian Boorman:

    It sounds like your problem might be related to errata item UCS10.

    The DCO has jitter because the modulator is used to shift between two frequencies with the intent of the average being accurate. At high bit rates this can be a problem even if the conditions of UCS10 don't pop up.

    Add to that the FLL changing the DCO settings and you have three sources of jitter on your bit clock. (FLL, DCO modulator, and bit clock modulator) You could eliminate the bit clock modulator by setting the DCO to an integer multiple of your bit rate.
  • Guru 46710 points

    In reply to David Schultz36:

    >You could eliminate the bit clock modulator by setting the DCO to an integer multiple of your bit rate.
    Very good advise. I occasionally use such approach on msp's that does not have FLL nor uart modulator, thou not for such a high baud rates. For 230400 bps closest frequency would be 15.8976 MHz

    In case msp430 is service processor for DSP, then apart from already suggested crystal oscillator there is one another solution: SPI
  • Guru 15690 points

    In reply to David Schultz36:

    Holy S**T! You're correct. This is exactly what I am seeing. Surprising that a design like this made the light of day.

    Thx,

    MikeH

     

  • Guru 15690 points

    In reply to Brian Boorman:

    Yes. I measured the 32khz crystal with both a 500MSPS analyzer and a spectrum analyzer.

    Thx,

    MikeH

     

  • Guru 15690 points

    In reply to MikeH:

    Clemens,

    Now that I understand what you mean, I am going to attempt to use my XT2 (8MHz) to directly drive SMCLK. Thanks.

    Thx,

    MikeH

     

  • Guru 46710 points

    In reply to MikeH:

    >This is exactly what I am seeing
    You see FLL rollover? If you can be flexible with frequency selection, you (your software) can try to runtime-find/calculate frequency that is safe against rollover and maybe even is integer multiple of baud rate.

    >Surprising that a design like this made the light of day.
    Knowing low power constraints that design is very ok. Not that much low power applications requires low jitter clock.

  • In reply to MikeH:

    MikeH
    ... You're correct. This is exactly what I am seeing. ...

    You mean you see USC10 -- a silicon bug that has been fixed a long time ago.

    What is the silicon revision you are using? The current revision is K. USC10 was present in revision C, D, and E only.

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.