MSP430G2553 DCO and Baud Rate Variation

Hello Paul,

Are there any similarities in the units that you've noticed are faulty, such as the revision number, device markings, or device packaging? With what percentage of units are you noticing this issue? Perhaps you could try using a different DCO frequency or baud rate just to see if changing those affect the issue. Also, is it possible for you to share your initialization code?

Regards,
Ryan

Ryan:

Only did about 5 units, all have the exact same markings. Of the 5 prototypes I’ve worked with, 2 exhibit the problem.  Here is the initialization code:

  // Stop watchdog timer to prevent time out reset

  WDTCTL = WDTPW + WDTHOLD;

 

  // Initialize hardware and software

 

  do

  {

    IFG1 &= ~OFIFG;                     // Clear OSCFault flag

    for (i = 0x47FF; i > 0; i--);       // Time for flag to set

  }

  while ((IFG1 & OFIFG));               // OSCFault flag still set?

 

// Calibrate DCO frequency to 1 MHz

  BCSCTL1 = CALBC1_1MHZ;

  DCOCTL = CALDCO_1MHZ;

 

// BRG init:

 

  // This code sets up the BRG to run from DCOCLK -> SMCLK.

  UCA0CTL0 = 0;                            // 8-bit character, UART mode, Async mode

  UCA0CTL1 |= UCSSEL0 + UCSSEL1;              // BRCLK = SMCLK

  UCA0BR0 = 104;                             // 1 MHz/9600 = 104

  UCA0BR1 = 0x00;                             //

  UCA0MCTL = UCBRS0;                        // Modulation = 1 (SLAU144j p.424)

  UCA0CTL1 &= ~UCSWRST;                          // Initialize USART state machine

  IE2 |= UCA0RXIE;                            // Enable USART0 RX interrupt

 

Let me know and thank you.

Make sure the following lines are included in the initialization:

P1SEL = BIT1 + BIT2;
P1SEL2 = BIT1 + BIT2;

These lines differentiate the pin functions between I/O port or peripheral module, the latter of which is desired in this case. Not having these bits set could be the cause of your problem. You can also use UCSSEL_3 in place of UCSSEL0 + UCSSEL1 for the UCA0CTL1 register, but this is not necessary since either will source BRCLK from SMCLK.

Out of curiousity, have you noticed whether your application or a terminal emulator such as Tera Term is able to communicate successfully even with the jittery baud rate?

Regards,
Ryan

Those lines are included. I didn't copy them because they weren't relevant to the problem at hand. 

Prototypes with the jittery baud rate are not able to communicate with the destination device due to the jittery baud rate.  Prototypes with stable clocks are able to communicate successfully 100% of the time. I haven't tried connecting a terminal emulator yet, but I'll try to fit it in in the next couple of days

This is very strange because a baud rate of 9600 with a G2553 is a common setup and I have yet to hear similar issues of the sort. Don't both trying to connect to a terminal emulator, failure to communicate with the destination device is proof enough that the jittery baud rate is most definitely out of an acceptable range.

Did these failing G2553s ever have code uploaded to them previously or are they brand new? Perhaps try a mass erase of the flash and then re-program them to see if anything changes.

I had a similar problem in the past and I discovered that the info A segment was erased, so I added these lines of code to my project

if (CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF)
{
while(1); // If cal constants erased, trap CPU!!
}

Anyway, before doing the mass erase/flash as Ryan suggested, could you please dump the Info A segment from the failing units and compare them with the not failing units.

Regards

Ryan, you're right that 9500Bd on the G2553 are quite common, but this common case usually uses a 32768Hz crystal (shipped with the LaunchPad) as base frequency. This results in a large bit error (32768/9600 ? 3.41, so timing is /4 or /3 with a large error) but does not jitter.

David's guess with erased calibration values is quite good (and there is a program that can restore them by using the 32768Hz crystal as reference).
I just wonder what Paul meant with 'jitter' in his post: Does the baudrate constantly change on one single unit, or does it simply vary for different unit (which is variation, not jitter)?
If the problem are the calibration constants, the baudrate shouldn't have a jitter (only a drift with temperature). It would simply set the DCO to its highest possible frequency (if both values are 0xFFFF), or its lowest one (if both are 0). However, in both cases , I'd expect the resulting DCO frequency and therefore baudrate to be way further off (by a decade or more). So I guess that the value for BCSCTL1 is correct but the one for DCOCTL is wrong, which would result in a DCO clock speed of 0.7 to 2MHz. Still, a value of 0 or 0xFFFF (erased/not set) wold not explain the baudrate range observed.
So my guess is that the calibration values have been accidentally overwritten with values from a different device (e.g. in an attempt to restore them after an accidentally erase) without doing a real calibration. Unfortunately, this case can't be detected except by comparing the resulting DCO speed to a known frequency - or observing a broken communication. :(

It is possible to output SMCLK (driven by DCO) to P1.4 and check the DCO frequency it with a scope. This way, the calibration values can also be restored by try and error. Note that the DCO clock output always has some jitter (up to 8% for two adjacent clock pulses) due to modulation. Calibration must be done for the average frequency (measured over 32 clock pulses, as modulation has a 32-step pattern), not for a single clock pulse.

I have used several G2553 with the DCO set to 1MHz sourcing the UART at 9600 baud and had never a problem with it. A variation of 8500 to 12000 baud (measured with oscilloscope?) is much too far off. As DavidL said, please read out InfoA of those devices and look if the constants are still available.

Here are some constants of a G2955 that was laying around - just as an example:

0x10F6:   0x01   <- TAG_DCO_30
0x10F7:   0x08   <- LENGTH OF DCO VALUES - 8 bytes
0x10F8:   0xD6   <- CAL_DCO_16MHZ
0x10F9:   0x8E   <- CAL_BC1_16MHZ
0x10FA:   0x63   <- CAL_DCO_12MHZ
0x10FB:   0x8E   <- CAL_BC1_12MHZ
0x10FC:   0xCA   <- CAL_DCO_8MHZ
0x10FD:   0x8C   <- CAL_BC1_8MHZ
0x10FE:   0x92   <- CAL_DCO_1MHZ
0x10FF:   0x86   <- CAL_BC1_1MHZ

I would try JMG's suggestion with outputting the SMCLK at a pin of the mcu.

Dennis