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.

CCS/MSP430FR2532: Baud rate issue

Part Number: MSP430FR2532

Tool/software: Code Composer Studio

Hi all,

I have a project with MSP430FR2532 that will need to use UART at baud rate of 57600 because the default baud rate of the other side is at 57600. During development, communication between MSP430FR2532 and FTDI USB-UART adapter (FT232R) works perfectly fine at 9600, 19200, 38400. But once I increased baud rate to 57600, message sent from FR2532 to FT232R can always be recognized, but message sent back from FT232R to MSP430 is corrupted from time to time, particularly the first chunk of message, usually first 10 bytes or so.

The following is code I used to initialize clock and UART

// Setup clock
__bis_SR_register(SCG0);                 // disable FLL
CSCTL3 |= SELREF__REFOCLK;               // Set REFO as FLL reference source
CSCTL0 = 0;                              // clear DCO and MOD registers
CSCTL1 &= ~(DCORSEL_7);                  // Clear DCO frequency select bits first
CSCTL1 |= DCORSEL_3;                     // Set DCO = 8MHz
CSCTL2 = FLLD_0 + 242;                   // DCODIV = 8MHz
__delay_cycles(3);
__bic_SR_register(SCG0);                 // enable FLL
while(CSCTL7 & (FLLUNLOCK0 | FLLUNLOCK1)); // Poll until FLL is locked
CSCTL4 = SELMS__DCOCLKDIV | SELA__REFOCLK; // set default REFO(~32768Hz) as ACLK source, ACLK = 32768Hz, default DCODIV as MCLK and SMCLK source

// Initialize UART1
UCA1CTLW0 |= UCSWRST;
UCA1CTLW0 |= UCSSEL__SMCLK;

// Baud Rate calculation
// 8000000/57600 = 138.889
// OS16 = 1, UCBR1 = 8, UCBRF1 = 10
// Fractional portion = 0.889
// User's Guide Table 21-4: UCBRSx = 0xF7
UCA1BR0 = 8;                               // 8000000/57600/16
UCA1BR1 = 0x00;
UCA1MCTLW = 0xF700 | UCOS16 | UCBRF_10;
UCA1CTLW0 &= ~UCSWRST;                      // Initialize eUSCI
UCA1IE |= UCRXIE;                           // Enable USCI_A1 RX interrupt

Not sure if it is related, MCU will stay in LPM3, wake up either every 100ms or one message is received from UART1/FT232R.

What could I be missing here? Some other posts reported FR2532 works just fine at 57600 or even at 115200.

  • Hello Zhiyoung,
    as you provided just the initialization code, I can give you just some indications where to look into.
    From your statements I understood, you're operating the MSP430 in LPM3. This means, the MSP430 CPU and DCO is in shut down, and thus need to startup. The startup time specified in the datasheet is typ. 10µs. This is just a typical value. The bit time of a pulse at 57600baud is 17.4µs. Thus even when you assume a perfect typical startup with 10µs, you'd face a more than half a bit period delay in sampling the incoming data from UART. This is probably already the first fundamental issue.
    There are two possible ways, how to handle this. 1st is a clean one, not going to LPM3 but remain at least in LPM0, where the startup time is much shorter (worst case 200ns + 2.5 / fDCO). The 2nd is a tricky one, switching the UART RX IO to GPIO interrupt function, when going to LPM3, sacrificing the 1st byte of the UART communication and just using it for wake up from LPM3, then switch with the end of the 1st byte back to UART function. But this is quite tricky and not really reliable.
    Other additionally contributing aspects might be too late readout of the RX buffer. This might be related to other code portions, not visible here and/or the construction of the UART ISR.
    But the use of LPM3 and the related startup aspects are with high probability the main issue.

    Best regards
    Peter
  • Hi Mr. Spevak,

    Tanks for the quick response. The startup time of DCO is what I missed. I had my suspicion but didn't do the actual calculation. Once I let FR2532 only go into LPM0, my code starts to work.

    To answer your question, I just transferred bytes from UCA1RXBUF into a ring buffer in ISR. That shall explain why only the first chunk of received messages were corrupted.
  • Hi Mr. Li,
    many thanks for your feedback and clarification. As it seems, your problem is solved, thus I am closing the thread.

    Best regards
    Peter

**Attention** This is a public forum