MSP430F5528: MSP430F5528 UART cannot recognize more than half of ASCII table characters

Sergey Teterin

Part Number: MSP430F5528

Hello!

I ask for help in solving the following problem: I submit characters from the terminal program (PuTTY) to the input of the UART receiver, in the RX interrupt I put the received symbol to the transmit buffer, but I cannot correctly receive more than half of the ASCII table symbols, instead of the symbol I receive 0xFF. I see correct test message after UART initiated, so I suspect that TX part works well. The second problem is that UART starts transmitting the symbol without waiting for the reception to end. Code and screenshots of the logic analyzer are attached.

I would be very grateful if this problem is solved.

Code

// Init UART
static void msp430_uart_init()
{

 // Put the USCI state machine in reset
 UCA1CTL1 |= UCSWRST;
 
 // P4.4,5 = USCI_A1 TXD/RXD
 P4SEL |= BIT4 | BIT5;
 UCA1CTL1 |= UCSSEL1;
 UCA1BR0 = 34;   // 115200
 UCA1BR1 = 0;
 UCA1MCTL |= ( UCBRS_2 | UCBRS_1 );  // 115200 --> 6
 
 // Take the USCI state machine out of reset
 UCA1CTL1 &= ~UCSWRST;
 
 // Enable the RX interrupt.
 UCA1IE |= UCRXIE;

 puts_u1("HELLO!\r\n");   // saw this correct 
}

// Interrupt handler
#pragma vector = USCI_A1_VECTOR
__interrupt void USCI_A1_ISR(void)
{
    volatile uint8_t symbol;

    switch(__even_in_range(UCA1IV,4))
    {
    case 0:break;                             // Vector 0 - no interrupt
    case 2:                                   // Vector 2 - RXIFG
        symbol = UCA1RXBUF;
        putchar_u1(symbol);
        break;
    case 4:                                   // Vector 4 - TXIFG
    break;
    default: break;
    }
}

// Send debug info
// Send char to UART1
void putchar_u1(uint8_t ch)
{
    while(!(UCA1IFG & UCTXIFG)) {;}
    UCA1TXBUF = ch;
}

// Send string to UART1
void puts_u1(uint8_t *str)
{
    while(*str)
    {
        putchar_u1(*str++);
    }
}

over 6 years ago

0 Keith Barkley over 6 years ago

Guru 41995 points

I don't do registers, I am a DriverLib() man myself, but do you have it set for 7 bit mode and not 8 bit?

0 Sergey Teterin over 6 years ago in reply to Keith Barkley

Prodigy 80 points

Keith, thanks for reply.
Here it is something else. I did not quite correctly describe the problem - the digits and symbols 'a' to 'd' and 'n' to 'w' are taken incorrectly, both the lower or the upper case, this can be seen on the screenshots where is the reception of two adjacent symbols. I do not use national symbols, so 7 bit or 8 bit format doesn't matter.I suspect that using the DriverLib API will not solve this problem.

0 Peter Dvorak over 6 years ago in reply to Sergey Teterin

Expert 2740 points

case 2: // Vector 2 - RXIFG

symbol = UCA1RXBUF;

putchar_u1(symbol); // This is probably a bad idea in an ISR For echo use registers

break;

0 Sergey Teterin over 6 years ago in reply to Peter Dvorak

Prodigy 80 points

Yes, Peter, I fully agree with this and use deferred interrupts as much as possible. It all started with a search for the reason why such simple code doesn't work.

#pragma vector = USCI_A0_VECTOR

__interrupt void USCI_A0_ISR(void)

void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)
{
    volatile uint8_t symbol;

    if(UCA0IFG & UCRXIFG != 0)
    {
        symbol = UCA0RXBUF;
        serial_buf[head++] = symbol; 
        if(head == max_idx)
        {
            head = 0;
        }
        if(symbol == '\n')
        {
            // tell upstairs
            // ...
            LED_RED_TOGGLE; 
        }
    }
}

0 JD Crutchfield over 6 years ago in reply to Sergey Teterin

TI__Mastermind 28955 points

Hello Sergey,

Unfortunately, I am unable to review the software in detail currently, but I wanted to point you to the UART software examples for this device, found here: dev.ti.com/.../node

There are some UART Echo examples that you should be able to run as is for testing.

Please test these and let us know if they work for you.

Thanks,
JD

0 Bruce McKenney over 6 years ago in reply to Sergey Teterin

Guru 95935 points

These are the symptoms of a questionable clock. First guess is that SMCLK isn't quite 4MHz (within 3%). Try:

1) putting SMCLK out on P2.2 and measuring it with your scope

and/or

2) posting your clock initialization code

0 Sergey Teterin over 6 years ago in reply to Bruce McKenney

Prodigy 80 points

Bruce, thank you very much for the hint, I checked the frequency of the SMCLK and it was twice as high as the frequency of quartz (using it on XT2). So I changed the initialization constants of the UARTs and got rid of the problem. I'm newbie with MSP430,so maybe I'm forgot to init clocks properly.
Thanks a lot!

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5528: MSP430F5528 UART cannot recognize more than half of ASCII table characters