MSP430F1611 UART Problem - 115200bps - SMCLK 1MHz

Hi Samuele,

There's another interesting thread ending right now about the USB-UART backchannel that his drifted onto this very topic of clocking.  You may find some of it interesting and useful.

How are you convincing the DCO to run at 4 MHz?  If it is accurately 4 MHz as you describe, then you'll have better luck running SMCLK at full DCO speed.  I'm guessing however that the DCO isn't running accurately at 4 MHz and that is really going to be the biggest hurdle.  If you have a 32768Hz crystal as a reference, you can either do a software FLL to enforce a target DCO speed, or you can measure the DCO speed and calculate the baud-rate divisor at runtime.

Jeff

Hi

I am now struck with the same problem . 1 MHz SMCLK and 115200 baud rate . I see transmission errors in the data .

Data sent and received for this baudrate dont match .

How did you fix this ?

Hi,

in my case the problem was caused by a wrong procedure in DCO calibration.

So, I started using the TI DCO_Library (search for slaa336a on TI web site) to calibrate the DCO, and then it started working correctly.

Currently, my settings are MCLK = 4MHz, SMCLK = 1MHz and UART is configured like this:

U1TCTL = SSEL1;
U1BR0 = 0x09;
U1BR1 = 0x00;
U1MCTL = 0x08;

Hope to be of help for you.

Regards,

Samuele.

Jenitta Rex said:

1 MHz SMCLK and 115200 baud rate . I see transmission errors in the data .

Hmm, 115200Bd on 1.0MHz clock gives a TX error of up to 8% and an RX error of up to 16% regarding the bit timing. That's already far outside the RS232 specs. And this is with a perfect 1MHz clock. Else the clock error adds to this.
The maximum relibale baudrate with 1MHz clock is 38400Bd. Above, you may get errors, depending on how sensitive the other side is (or how far off of the exact baudrate, probably, due to Murphy's law, in the opposite direction)

Hi,

I usually use the mspgcc baudrate calculator to check the UART settings.

The baudrate calculator is available at this web page:

http://mspgcc.sourceforge.net/baudrate.html

With a clock of 1024 * 1024 = 1048576 Hz and a target baudrate of 115200, I obtain this results:

/*

 uart calculator: http://mspgcc.sourceforge.net/baudrate.html

 this program license is at: http://www.fsf.org/licenses/licenses.html#GPL

 this program is distributed WITHOUT ANY WARRANTY

 clock: 1048576Hz

desired baud rate: 115200bps

division factor: 9.1

effective baud rate: 115228bps

maximum error: 0.4662us 5.37% 

time table (microseconds):

event desired effective error error%

startbit->D0 8.68 8.58 +0.0974 +1.12

D0->D1 17.36 17.17 +0.195 +2.25

D1->D2 26.04 25.75 +0.292 +3.37

D2->D3 34.72 34.33 +0.39 +4.49

D3->D4 43.40 43.87 -0.466 -5.37

D4->D5 52.08 52.45 -0.369 -4.25

D5->D6 60.76 61.04 -0.271 -3.12

D6->D7 69.44 69.62 -0.174 -2.00

D7->stopbit 78.12 78.20 -0.0762 -0.88

end of stopb 86.81 86.78 +0.0211 +0.24

*/

UBR00=0x09; UBR10=0x00; UMCTL0=0x10; /* uart0 1048576Hz 115228bps */

UBR01=0x09; UBR11=0x00; UMCTL1=0x10; /* uart1 1048576Hz 115228bps */

Reading the report, I see that, with this settings, I get maximum error of 5.37%.

Is the mspgcc baudrate calculator wrong? I have used this settings and the UART communication works correctly...

My error values were directed to Jenitta's 1MHz on USCI (Which I remember form another thread), not your 1.05MHz on USART. And I got the value from the 5x family users guide.

Note that the baudrate program was written for the USART, not the USCI, which has a different modulation mechanism.
And the values in the USART baudrate table in the 1x family users guide look closer to the program output (-5/7% for TX and +-7 for RX, using UMCTL1=0x08).

Well, I'm surprised that the older USART got better timing results for the same clock.

However, 5.37% is still outside the specs (which IIRC define +-5% for the sum of transmitter and receiver). And this is assuming an exact clock speed, so the real error is likely higher.
On the other side, the error is not a constant or average error (in which case a 5% baudrate error would accumulate to 1/2 bit size after 10 bits and definitely procude an error). Modulation causes the accumulated timing error to grow and shrink during subsequent bits. So usually, a higher temporay error is acceptable.
The cumulative badurate error caused by an inaccurate clock is weights much more.