UART Baud Rate Problem

Hi Burak,

Can you verify ACLK by driving it onto P2.0 for example?  I suspect XT1 is either not functioning or not installed.  In that case, ACLK reverts back to the slow VLOCLK, which might make your serial I/O appear to be around 2400 baud.

Jeff

Actually i ignored the XT1 fault flag part because when i debug the code it stacks the defined space below. But when i make the defined space comman it works but on 2400 baud.

JSEL0 |= BIT4 + BIT5;

CSCTL0_H = 0xA5;
 CSCTL1 |= DCOFSEL0 + DCOFSEL1;                        // Set max. DCO setting
 CSCTL2 = SELA_0 + SELS_3 + SELM_3;                        // set ACLK = XT1; MCLK = DCO
 CSCTL3 = DIVA_0 + DIVS_3 + DIVM_3;                            // set all dividers 
CSCTL4 |= XT1DRIVE_0;
CSCTL4 &= ~XT1OFF;

 
do                                          //When this loop is done command the code works but on 2400 baud
{
CSCTL5 &= ~XT1OFFG;                                
                                                          // Clear XT1 fault flag
SFRIFG1 &= ~OFIFG;
}while (SFRIFG1&OFIFG); // Test oscillator fault flag
 

I don't know what the problem is (unless the header files contain errors so that e.g. DIVA_0 is actually DIVA1 and selects /4 divider) But I'm rather unfamiliar with the FR families clock system (I didn't use it myself so far and didn't read too deep into the users guide yet)

The questions for ACLK output (on ACLK output pin) is still unanswered. Is it really 32768Hz?

However, getting 9600Bd from 32768Hz clock is far outside the UART specifications. 32768/9600 is 3.41. So the individual bits are 3 or 4 clock cycles long, resulting in huge bit timing errors way outside teh RS232 specification. 4800 or (even better) 2400Bd gives a way more reliable transmission.

Jens-Michael Gross said:

getting 9600Bd from 32768Hz clock is far outside the UART specifications.

Actually, I can defend 9600 baud from a 32768 Hz reference.  It is one of the MSP430's most interesting capabilities.  And it is 100% reliable in most applications.  If you have a 32768Hz crystal, and if the remote end of the link is a PC or other UART with a traditional clock reference, then the link is 100% reliable.

Remember the old days, when we used to allow clock skew between the two endpoints of up to 4%.  By the time a frame got to the stop bit, the sampling could be off by almost half a bit.  But it works.  As long as the sampling process aligns with more than 50% of the bit, it will sample correctly. 

Well the sampling process of the eUSCI (in the FR series) aligns with at least 67.8% of every bit.  It is rock solid.  It even leaves room for some clock skew, maybe not up to 4%, but 1% is no problem and theoretically 2% is the limit.  I have all of the analysis in a spreadsheet.  With modern equipment, it's easy to provide less than 2% clock skew.  (For reference, the USCI in the 2x and 5x/6x series did not provide as much modulator flexibility, so it tolerates only up to 0.4% clock skew -- still easy with a 32768 Hz crystal.)

Bottom line: Use a 32768 Hz crystal for 9600 baud with 32kHz reference.

Jeff

It's not the sampling process on teh MSP side I'm talking about. You don't know what's on the PC side. And 9600Bd from 32768Hz gives you a bit timing error of up to -21%!
It may work with one and refuse to work with anopther. One user will use it with a real COM port, one will use an USB/SER converter of differend brands. That it worked for you so far doesn't mean it will always work. And there's nothing worse than a whole product charge coming back because the out-of-spec UART isn't compatible to the latest (still spec-compliant) smartphone or PC chipset or whatever.
"it always worked so far" is no excuse for working outside the specs. It only works until it stops working. And then nobody but you is to blame. Like driving too fast or drunk. If you are caught, it's no excuse that you didn't have an accident so far.

Yes, the remote end (eg, PC, USB/SER converter) must meet tolerances to ensure 100% reliability.  However, the receiver tolerances are very permissive.

The maximum sampling error permissible in the remote end depends on the MSP430, as follows:

USART (UxMCTL = 0x29):  32.8%

USCI (UCBRSx = 3):  28.9%

eUSCI (UCBRSx = 0x94):  32.8%

These are very permissive so I don't think any PC or USB/SER converter would exceed these tolerances.  If they did exceed these tolerances, they probably wouldn't meet the RS-232 "spec" you are referring to.

The tolerances relating to the remote end transmitting are actually tighter than the tolerances relating to the remote end receiving.

Jeff

I thing the setting you did here is write .

But you check the clocking system.Have you used internal clock or external clock?

There might be a problem due to ACK is not driven proper..You can check that by configuring port pin by ACK & check clk frequency on oscilloscope.

Check that ACK is = 32768Hz.on that port pin.

If you have 32.768KHz crystal as timing reference, you can recalibrate and overwrite factory DCO flash constants to "uart-friendly" frequency like 1.2288 MHz or 7.3728 MHz. All you need is to modify constants in "dco_flashcalib" code example. If this is all about low power consumption, then there's other solution: instead of 32KHz, use 38.4 KHz "fork" oscillator. Then you just need to run your real-time clock using slightly different (mathematical) approach.