This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UART sending random bytes - MSP430G2553

Hello. I have configured UART at 9600 baud rate, running off of the 16MHz SMCLK. However I am receiving the wrong characters on the terminal (I'm using Putty to display). For example when I send 'C' I receive "GtAGtGtGtA" in an order similar to that.

Here's my code:

void configUART()
{
	UCA0CTL1 |= UCSWRST; // set software reset of uart
	UCA0CTL0 = 0; // default mode...8 data bits, 1 stop bit, async
	UCA0CTL1 |=	BIT7; //SMCLK, which is set to 16MHz
	// for baud of 9600 we want prescalar = 1666; that's 130 + 6*256
	UCA0BR1 = 6;
	UCA0BR0 = 130;
	UCA0MCTL |= UCBRS_6; // UCBRSx = 6
	P1DIR |= BIT2; // select output pin
	P1SEL |= BIT2;	// choose UART option for pin
	P1SEL2 |= BIT2;
	UCA0CTL1 &= ~UCSWRST;
}
void main(void)
{
   WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
   configSubMainClock16MHz();
   configUART();

    _BIS_SR(GIE); // enable global interrupts
    while(1)
    {
    	while(!(IFG2 & UCA0TXIFG));
    	UCA0TXBUF = 'C';
}

I don't know why I'm getting such random transmission.

  • Hi,

    Try to clear UCA0TXIFG before sending the next character by

    IFG2 &= ~UCA0TXIFG;

    Regards,

    Juris

  • Hey thanks for replying. I tried that and the results remain the same.

  • Yes, according manual: "Writing to the transmit data buffer clears UCAxTXIFG".

    Could you check in (dis)assembler code is the 

    while(!(IFG2 & UCA0TXIFG));

    really compiled in your code - sometime an optimisator skip some code lines it think not usable.

    If not commpiled try:

    while(!(IFG2 & UCA0TXIFG)) _NOP();

    Regards.

  • Hi,

    Yes, it is compiled. Also, I removed it completely and the characters still get transmitted. They're still random, however.

    I'm seriously very lost.

    EDIT: Ok I got it. My SMCLK was configured incorrectly. Thanks for the help though.

  • Sufyan Alamad said:
    EDIT: Ok I got it. My SMCLK was configured incorrectly. Thanks for the help though.

    When writing software (especially at the low-level embedded driver level) you should test your functions to make sure they work properly before moving on to the next coding task.

    In this case, you could have programmed the GPIO pin to output either MCLK or SMCLK and made sure you had the proper frequency (ideally using a frequency counter, but an oscilloscope can provide a good in-the-right-ballpark measurement).

    I'm sure you'll add this to your lessons-learned memory.

**Attention** This is a public forum