• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 82 subscribers
  • Views 1865 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.

MSP430 USCI-Uart Silicon Problem?

MikeH
Guru 15580 points
Other Parts Discussed in Thread: MSP430F5515, TMS320C5515

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.

 

  • 0
    Guru 243870 points
    The DCO has jitter. At such high baud rates, the clock should come directly from a crystal.
  • 0 in reply to Clemens Ladisch
    Guru 15580 points

    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.

  • 0 in reply to MikeH
    Guru 25210 points
    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?
  • 0 in reply to Brian Boorman
    Guru 18885 points
    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.
  • 0 in reply to David Schultz
    Guru 46710 points
    >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
  • 0 in reply to David Schultz
    Guru 15580 points
    Holy S**T! You're correct. This is exactly what I am seeing. Surprising that a design like this made the light of day.
  • 0 in reply to Brian Boorman
    Guru 15580 points
    Yes. I measured the 32khz crystal with both a 500MSPS analyzer and a spectrum analyzer.
  • 0 in reply to MikeH
    Guru 15580 points
    Clemens,

    Now that I understand what you mean, I am going to attempt to use my XT2 (8MHz) to directly drive SMCLK. Thanks.
  • 0 in reply to MikeH
    Guru 46710 points

    >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.

  • 0 in reply to MikeH
    Guru 58965 points

    MikeH said:
    ... 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.

  • 0 in reply to old_cow_yellow
    Guru 15580 points
    My two production runs use Rev E chips.
  • 0 in reply to MikeH
    Guru 58965 points
    Oh, well.
    Take comfort that you don't have BSL6, FLASH35, or USB11 ;)
  • 0 in reply to MikeH
    Guru 15580 points

    Success!

    Luckily, I was able to feed SMCLK from an existing 8MHz crystal on XT2. Nice, simple (firmware) fix for a potentially ugly production problem.

    I have submitted a recommendation to TI Documentation that they add a warning to the User Guide about using the DCO for high baud rate applications.

    Thanks for all of the positive helpful suggestions!

**Attention** This is a public forum