UART Clock Issue / Accuracy / DCO

[Optronik 0]

I am using a MSP430G2553 and communicate with it to a PC using the UART interface. The baud rate is 9600. For accuracy reasons (sic) I selected ACLK clocked by an external 32.768kHz crystal to provide the clock for the UART module. Well, it worked until recently the PC was not recognizing the sent characters. A bit of research showed that the baud rate error in that configuration is quite significant (20%).

Now the idea was to use a higher frequency to clock the UART in order to minimize the baud rate error. Well, I was all the time under the assumption that the DCO can use the external crystal together with a PLL to generate a higher frequency.

After reading through the data sheet it seems that it is not the case! DCO is relying in an inaccurate RC element rather than to use the low frequency crystal.

 

Now, having these 2 options, what is the best to do? Will be DCO at e.g. 16MHz with an inaccurate RC as a source provide better baud rate error than the 32kHz crystal? 

[enl 227]

DCO will generally be within 5% (max over operating range is 6%, but it is usually better) when properly calibrated. If the factory data has not been overwritten, then you can set the DCO to one of four calibrated frequencies, including 1MHz and 16MHz to keep within 5 or 6%.

 

You can check the calibration against the 32kHz xtal and trim the numbers to get closer, either by modifying the DCO constants or the settings for the UART clock.

 

If the 32KHz xtal is already there, then by using more advanced features of the UART clock, you can do a lot better using the baud rate modulator than with only the divider. See slau144, section 15 (in slau144i, it is page 430, and subsection 15.3.9) where one of the examples is specifically 9600baud using the 32kHz xtal.

[enl 227]

I was going to add to the original post when the system went down, so:

 

The 20% error referred to in the table (15-4) is the worst error on an individual bit. The overall error for a given byte is significantly less. A 20% error for a single bit frame shouldn't be a bit issue, as the sample should be taken by the receiver at the center of the nominal bit frame. If both sender and receiver are off by 20%, in opposite directions, there is still some margin. I have used the 32KHz xtal with baud rate modulation without problems, though my default is to just clock the UART whatever DCO frequency I am otherwise using, if the DCO is active. (DCO is not an option in an application that spends most of the time in one or another low power mode)

 

Something you might try is set the UART transmit to 2 stop bits. This will provide margin at the receiver for resynch on the next byte. It should not be needed, but I have seen cases over the years where it is needed.

[Optronik 0]

I did some more research on that topic. Apparently is the MSP430G2553 not like other MSP430 able to do the required modulation for 9600 baud. Reason is that the modulation register only allows a reduced number of modulation options.

 

Options are so far are:

- reduce to 4800 baud (modulation on G2553 seems to work here)

- use 38.400kHz instead of 32.768khz crystal

- use DCO which can be calibrated in system by using accurate 32.768Khz crystal as reference

 

I am still wondering why the LFXT can not be used as an input for the DCO. This would resolve some other issues as well.

[enl 227]

Reference for reduced number of mod modes for g2553? I see nothing in the docs, and it has a UCA0MCTL register with no notations that I can see indicating that modulation is modified from the documentation in slau144. I will not exclude the possibility that I am missing something, as I can't recall for sure if I have used modulation on a g2553, though I think I have.

[Optronik 0]

Well, there is a nice document explaining how to calculate the correct modulator value:

http://www.win.tue.nl/~johanl/educ/RTcourse/MSP430%20UART.pdf

 

According to this (page 14, table 2) the modulator value should be 0x4A for ACLK 32768Hz and baud rate 9600.

 

Looking into the G2553 datasheet (http://www.ti.com/lit/ug/slau144j/slau144j.pdf), chapter 15.4.5, shows the modulator register.

Bit 0 is UCOS16 which should be 0 for low frequency mode (per section 15.3.9.1 Low-Frequency Baud Rate Generation).

Bits 4-7 are ignored if UCOS16 is 0.

 

This leaves bits 1-3 for possible modulation values. So how would I use the modulator 0x4A on these 3 bits ?

[enl 227]

Ah... I see.

 

UCAxMCTL 15.4.5: Bit 0 is UCOS16. Bits 1, 2, and 3 are for the modulation select. A modulator value of '3' is desired here (as per table 15.4) with a divider of 3. This gives best approximation to 9600 average by being an effective divider of 27/8 (three and three eighths). [32768/9600=3.41, which is about 1% greater than 27/8]. The modulation pattern produced by UCBRS=3 is 0x4A (see table 15.2.... note that the bits are shown in order used, which is low to high order)

 

Therefore, you want UCA0MCTL to be 0bxxxx0110. The high order four bits don't matter, as they are ignored when UCOS16 is 0. I would use 0x06 for UCA0MCTL.

[Optronik 0]

Thanks for looking into this. However, I just checked what settings I used in my code. UCA0MCTL was loaded with 0x06 when the issue got present.

 

I just took a look at table 15-2 to find the 0x4A relation to UCBRS=3. I might be blind but I can not see how this should correlate:

 

0x4A = 01001010

UCBRS=3 : 01010100

 

 

As a temporary fix I changed BRCLK to DSO generated clock. I will see if that improves the situation.

[enl 227]

Reverse the bit order of UCBRS=3 data bits, since they are given least to greatest in the table, which actually gives 0x2A, which gives slightly greater max error than the 'ideal' 0x4A, but the same average rate. I am not quite sure why they show 'ideal' modulation in slaa049 rather than the ones that the UART can actually do, but that is what they show.

 

If you had UCA0MCTL = 0x06, then that was correct for 32KHz clock.

 

DCO clock will allow you to use a larger divisor, so you can get much closer to the correct frequency. It should be more than accurate enough. As I said, It should be fine with the 32KHz clock and appropriate divisor and modulator setting. The other question is: what are you using for the PC side? The launchpad board? a different serial device? The launchpad board should be OK with the modulated clock, in my experience, but some of the USB-to-serial devices I have seen are not very close on the bit rate. That might be a contributor.

[Optronik 0]

I am using a Prolific USB to serial cable in order to communicate with the computer. However, the MSP430 will not only communicate with the computer in the final project, it will also communicate with a GPS sensor (which also transmits at 9600 baud). So since I encountered already issues with the connection to the PC it is quite likely the same problem goes on with the GPS. Bad thing here is that it may remain undetected.

 

The issue was not like just one character was missing/wrong, the whole bit flow seemed to be shifted so that the PC/Prolific chip could not resync.

[enl 227]

Odd.

 

Good luck ironing the rest of it out

[zeke 693]

I think that you should replace the Prolific usb uart with a CP2101 or FT232RL based unit.

 

It is my impression that the Prolific units are known to be flakey.

[KatiePier 73]

I am still wondering why the LFXT can not be used as an input for the DCO. This would resolve some other issues as well.

 

Hi @@Optronik,

 

Just a note - Your mention earlier about using 32kHz with FLL to help set the DCO is actually what is done on some of the other newer MSP430 device families. You may want to take a look at the MSP430FR2033 for example (its big brother with LCD is also found on MSP-EXP430FR4133 Launchpad). This device uses the external crystal as an input to an FLL with the DCO to constantly keep tuning and adjusting the DCO to a specific frequency. Something similar is also done on MSP430F5xx/6xx devices if you ever use those.

 

So what you are asking about is something that is done, it's just not a feature on the particular part you are using. Some people have created software FLL algorithms on their own though, using a timer to compare the output of the DCO to the 32kHz crystal (# of DCO ticks in one XTAL period), then in software adjust the DCO control bits accordingly. This is more involved and software heavy though than on the parts where this is done in hardware.

 

Regards,

Katie

[Optronik 0]

@@KatiePier

 

thanks for this info. I choose the G2553 because of the compact package/pincount plus UART+SPI capability. FR2933 is a bit oversized.

I will stay with DCO for now, just hoping that the UART issue is solved.

Do you know at what temperature the DCO calibration values are measured?

[KatiePier 73]

@@KatiePier

 

thanks for this info. I choose the G2553 because of the compact package/pincount plus UART+SPI capability. FR2933 is a bit oversized.

I will stay with DCO for now, just hoping that the UART issue is solved.

Do you know at what temperature the DCO calibration values are measured?

@@Optronik,

 

See the datasheet www.ti.com/lit/gpn/msp430g2553 p. 30. You'll see under Test Conditions that the calibration is done at 30C and 3V.

 

The spec to the right then specs what tolerance you'll get off of this 30C/3V calibrated frequency when you use it across the full 0-85C at 3V, or across 1.8-3.6V at 30C, and across both -40-85C and 1.8-3.6V.

 

-Katie