• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430FR5959: Does it make sense to use DCO clock with big temperature swings?

Dan Mezynski
Prodigy 50 points
Part Number: MSP430FR5959
Other Parts Discussed in Thread: MSP430FR5969

 We are using the UART on the MSP430FR5969 to communicate with other boards(all with the MSP430FR5969) that could be at significantly different temperatures, with differences of >20C.
  Sometimes one board will be hotter than the others, and sometimes cooler than the others in an unpredictable way.  We can't easily simulate
  these temperatures until the system is deployed but we need to decide now how to implement this comm.
  Our current clock setup is using the DCO(Digitally Controlled Oscillator) but from reading the doc SLAA992.pdf it seems the clock frequency
  can vary with temperature, but I don't see that the doc says how much it can vary.
  Since we need the comm to be fast we are shooting for at least 230400 baud, but our tests seem to show that this is on the hairy edge of working.  With the temperature issues are we asking for trouble?
 
  Some engineers in our group are saying the UARTs are designed to deal with some variation in clocks and are asynchronous and the boards are in late stages of design so we will be ok.
  But it seems risky to me to use DCO, should change to a crystal oscillator?
 
  I would need more data on how much the DCO clock frequency can vary with temperature.
  Also, there may be times the temperature is above 85C, Will the DCO work ok higher than this?  does page 7 in SLAA992.pdf figure 2-1 say that the clock will vary by 4%?  


 

  • +1
    Guru 24585 points

    You seem to have missed the line in the device data sheet that specifies 0.01%/C

    Calculate what the maximum different between parts will be and look at what this does to the UART sample timing. Making sure that you have sufficient margin on the last bit.

  • 0 in reply to David Schultz
    Prodigy 50 points

    OK now I see that! It seems like 0.01%/C is very small, but then again for a 60 byte message, with 10 bits/byte would be 600 bits, if we use dt of 50C then it's a total of 0.5% so by the time it gets to the last bits in the message does it cumulatively add up to be a problem? 

    I guess I'm not sure how to do the analysis, it seems like long messages could maybe have a problem.

    Any comments would be welcome!

  • +1 in reply to Dan Mezynski
    Guru 24585 points

    The A in UART is for asynchronous. All timing is relative to the beginning of each start bit. The family guide goes into quite a lot of detail on bit timing and errors.

  • +1 in reply to Dan Mezynski
    TI__Mastermind 28075 points

    Hi Dan,

    To add to what David said here, the last bit is generally considered the most important when evaluating the consequences of clock error/mismatch between sender and receiver in UART, because that's where the error accumulates. Your 60-byte message should be sent with 60 start bits, and the UART will "resynchronize" at every start bit, and essentially you are starting your error accumulation over.

    So if you are only using a 10-bit (start + 8 bit data + stop bit) style UART, some people estimate that you can tolerate 50% error on that last bit, meaning 5% error overall, which can be interpreted as 2.5% mismatch at both the sender and receiver ends. More conservative estimates would bring that margin on the last bit down to 30% or 40% (3% to 4% allowable mismatch). 

    Table 22-5 of the Family Users Guide gives a summary of the additional transmit and receive error you can expect based on your UART settings. The preceding sections show how it was calculated. That process is pretty involved, so if possible I recommend sticking to one of the settings options we show in that table. That error should also be considered in addition to the frequency variation of the DCO (see note 2 of that table). 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 50 points

    Thanks to David and Brandon,

    The start bit being the beginning of the timing, and the beginning of the frame, so it makes sense that it's all contained in the frame.  I was thinking the the asynchronous UART was more tolerant of phase differences, but you have shown it's also somewhat tolerant of frequency dt as well.

    The DCO will work for us.

**Attention** This is a public forum