What's more precise: UART via crystal or DCO?

[Apr30 2]

I'd like UART to be as reliable as possible. Since baud rate 9600 is semi-standart I'd prefer to stick with that value.

 

Which option has more precise timing?

 

1) LFXT1CLK (32k crystal) -> ACLK -> UART

2) DCO (1MHz) -> SMCLK -> UART

 

slau144 says #1 has error rate 15.2% / 21.3% (TX/RX)

and #2 has 0.7% / 0.8%.

 

But DCO by itself is less precise than the crystal. So which one to choose?

[roadrunner84 466]

The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.

But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.

So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.

The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.

I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.

 

As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.

For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.

Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.

 

I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.

[Apr30 2]

Thanks for the detailed answer. By "more stable" you mean less slope of error over temperature range, right?

 

 

Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.

 

That probably saved me some hours of debugging.

[enl 227]

The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.

 

The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.

 

To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.

 

THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)

 

The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.

 

The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).

 

All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.

[Apr30 2]

Impressive answer. Thanks.

 

I've seen unexpected behavior when using SPI on UCB0 and UART on UCA simultaneously.

None of the errors from datasheet seemed applicable. So I wondered if that's due to UART being driven from crystal.

 

@@roadrunner84,

it seems FLL is not supported by G2553...

[roadrunner84 466]

Impressive answer. Thanks.

 

I've seen unexpected behavior when using SPI on UCB0 and UART on UCA simultaneously.

None of the errors from datasheet seemed applicable. So I wondered if that's due to UART being driven from crystal.

 

@@roadrunner84,

it seems FLL is not supported by G2553...

You can make FLL in software, this is the basic process.

Count a set number of LFXT/ACLK ticks in DCO/SMCLK ticks: Set a timer (can be the watchdog) to fire every X ticks of ACLK, set another timer to run on SMCLK. Reset both timers. Sample the second timer when the first timer fires.

Now you know how many SMCLK ticks go in X ACLK ticks, since ACLK is derived from the LFXT, you can tune your DCO (SMCLK source) to get closer to the desired value.

 

This of course takes time, time you may not have. But if you can spare a bit, add this FLL before every message you send over UART. If that's too heavy, sample every second or minute. Alternatively (if you don't need the reset on watchdog) have the timers run continuously in the background and do this stuff in the ISR.

[jazz 209]

I'd like UART to be as reliable as possible. Since baud rate 9600 is semi-standart I'd prefer to stick with that value.

 

If for your project low power is not main priority, and micro over UART exchanging more than few bytes, than don't stick with 9600 value, because MSP can go over 1 MBit, and use XT2 as MCLK / UART CLK source. Setup tool is here http://forum.43oh.com/topic/2640-uart-configurator/

 

I've seen unexpected behavior when using SPI on UCB0 and UART on UCA simultaneously.

None of the errors from datasheet seemed applicable. So I wondered if that's due to UART being driven from crystal.

 

I am guessing that "unexpected behavior" is due to your code, not to UART at 9600 driven from crystal. I am running dual UART / CDC bridges on MSP430F5510 (24 MHz MCLK from XT2) simultaneously on over 1 Mbps UART rate without "unexpected behavior".

[Apr30 2]

If for your project low power is not main priority

 

Well, it is... I hope 9600 is fine for occasional software updates.

 

I am guessing that "unexpected behavior" is due to your code, not to UART at 9600 driven from crystal.

 

That's what I thought too. But after double-checking over and over again I wondered if it's the hardware.