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.

Delays during UART transmission

Other Parts Discussed in Thread: MSP430F5325

Hi,

I'm programming an MSP430F5325, using Code Composer Studio and interfacing by way of the programming half of a Launchpad board that is connected to the spy-by-wire pins.  My goal is simply to send UART data out the UCA0TXD line at a reasonably fast baud rate like 115K.  While I'm basically having success, I'm finding that there seems to be a time lag of about .3 ms between each byte, and I haven't spotted in the docs any explanation about why this is or whether it's possible to eliminate it.  The following output from my logic analyzer illustrates what's happening:

Here's the basic code I've been using:

#include "msp430f5325.h"

void main(void) { 

  WDTCTL = WDTPW + WDTHOLD; // Stop WDT


  // Setup clocks.
  UCSCTL1 = DCORSEL_5; // Select basic DCO clock range (~2-54 MHz)
  UCSCTL2 = 488; // DCO = REFOCLK * 488 (32,768 * 488 = ~16 MHz)
  UCSCTL3 = SELREF_2;
  UCSCTL4 = SELA_3 | SELS_3; // ACLK = SMCLK = DCOCLK

  // Setup USCI for 115 kbaud UART.
  P3SEL |= BIT3; // P3.3=UCA0TXD
  UCA0CTL1 |= UCSSEL_2; // SMCLK = source for baud rate generation
  UCA0BR0 = 138; // SMCLK 16MHz => 115k baud (see MSP430x5xx Family User's Guide table 34-4)
  UCA0BR1 = 0; // SMCLK 16MHz => 115k baud
  UCA0MCTL = UCBRS_7; // SMCLK 16MHz => 115k baud (Modulation UCBRSx = 7)
  UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**
  

  // Main loop.

  int j = 0;

  while (1) {
    while (!(UCA0IFG & UCTXIFG)) ;
    UCA0TXBUF = j++;
    }
  }

I've tried both polling (as shown here) and also interrupts in order to get transmitted the second and subsequent bytes.  I've messed around with a number of other options, but have yet to eliminate the long idle period, which as you can see slows down the overall bandwidth of the transmission quite a bit (by about a factor of 3).  Thanks in advance for any suggestions!

Christopher

  • Hi Christopher,

    I see a couple of issues in your example:

    - You seem to be clearing SELM when you write UCSCTL4 (this is probably the main cause of the behavior you saw) 

    - Initialize the PMM if you are running >8Mhz

    - It's recommended to add a delay and clear clock fault flags when initializing the UCS

    You can find drivers and examples of UCS/PMM initalization in DriverLib, CoreLibraries or the C examples 

    Regards,

    Luis R

  • Awesome, thanks for the speedy resolution (not sure how I overlooked those SELM flags...)

**Attention** This is a public forum