Data Transmission - Serial Port

Mike,

What baud rate are you using?  Is the system timing based on a crystal?  If not, the DCO may be far enough off sometimes to take the baud rate out of tolerance.

Another possibility:  Are you waiting between sending characters? 

Mike

Mike said:

Mike,

What baud rate are you using?  Is the system timing based on a crystal?  If not, the DCO may be far enough off sometimes to take the baud rate out of tolerance.

Another possibility:  Are you waiting between sending characters? 

Mike

Hi Mike,

The text is being sent as a string with no delay between character transmission.

I'm just using an edited version of the msp430xG46x_uscia0_uart_9600.c program, with the baud rate at 9600.

The only changes I've made to that program was the removal of the echo function, and the addition of the TXstring function below based on the function from the EZ430 temp sensor program.

void TXString( char* string, int length )
{
  int pointer;
  for( pointer = 0; pointer < length; pointer++)
  {
    UCA0TXBUF = string[pointer];
    while (!(IFG2&UCA0TXIFG));              // USCI_A0 TX buffer ready?
  }
}

Could there be a problem be with this?

Mike

Mike,

The code seems OK.  There is a small problem with it, though I don't think it is causing the problem you see:  In TXString, you should put the while loop before the write to UCA0TXBUF.  Otherwise you could overwrite UCA0TXBUF if you call TXString twice in a row.

What about shifts in speed?  Is the baud rate clock ultimately based on a crystal?

Also, if you have access to an oscilloscope, you could look at the serial data coming out.

Mike

Thanks very much for your help Mike,

I have access to an oscilloscope so I'll try that out tomorrow, and I'll switch the while loop around.

I'm fairly new to programming with the board, so I don't know very much about how the clock is operated.

The description at the start of the code I'm using is as follows:-

//******************************************************************************
//   MSP430xG46x Demo - USCI_A0, Ultra-Low Pwr UART 9600 Echo ISR, 32kHz ACLK
//
//   Description: Echo a received character, RX ISR used. Normal mode is LPM3,
//   USCI_A0 RX interrupt triggers TX Echo.
//   ACLK = BRCLK = LFXT1 = 32768, MCLK = SMCLK = DCO~1048k
//   Baud rate divider with 32768hz XTAL @9600 = 32768Hz/9600 = 3.41 (0003h 03h )
//   //* An external watch crystal is required on XIN XOUT for ACLK *//   
//
//
//                MSP430xG461x
//             -------------------------
//         /|\|                      XIN     |-
//          | |                                 |      32kHz
//          --|RST             XOUT |-
//            |                                 |
//            |     P2.5/UCA0RXD|------------>
//            |                                 | 9600 - 8N1
//            |     P2.4/UCA0TXD|<------------
//
//   K. Quiring/ M. Mitchell
//   Texas Instruments Inc.
//   October 2006
//   Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.41A
//
//   Modified for the MSP430FG4816/F2013 Experimenter's Board by D Chandler
//******************************************************************************

Where it says an external watch crystal is required for XIN, XOUT, does this mean I have to add an external crystal to the board myself, or should there be one present already?

Mike

Mike2108 said:

Where it says an external watch crystal is required for XIN, XOUT, does this mean I have to add an external crystal to the board myself, or should there be one present already?

I believe the MSP-EXP430FG4618 experimenter board has the crystal across XIN/XOUT populated, but you should check this.  I base this comment on a picture of the board on the Product Folder site and not obviously your board.  Component X2 is the crystal in question.
The example code you mention above likely came from the MSP430FG461x C Examples (IAR and CCE) (SLAC118) which doesn't assume running on the MSP-EXP430FG4618 experimenter board.

Reviewing the MSP430x4xx Family Guide (SLAU056) in the UCSI Section, Table 19-2 and Table 19-4 suggest there might be some large TX error when using a 32768Hz clock and a baud rate of 9600.

Do you get a more reliable connection when configuring for 32768Hz and 4800 baud?  You would need to modify to the following:

  UCA0BR0 = 0x06;                           // 32k/3800 = 6.82
  UCA0BR1 = 0x00;                           //
  UCA0MCTL = 0x0E;                          // Modulation 7

BrandonAzbell said:

I believe the MSP-EXP430FG4618 experimenter board has the crystal across XIN/XOUT populated, but you should check this.  I base this comment on a picture of the board on the Product Folder site and not obviously your board.  Component X2 is the crystal in question.

The crystal is located on my board as well.

BrandonAzbell said:

Do you get a more reliable connection when configuring for 32768Hz and 4800 baud?

I modified the code to the 4800 baud rate, and also the terminal, but there was no improvement in terms of the amount of corruption occuring.

Also the situation has become far worse. I cannot now achieve any form of commmunication between the PC and experimenter board for any baud rate.

I've tried going back to the working transmission programs, including the original echo program, but it is not possible to get any kind of data communication, even corrupted data.

I believe now that perhaps the connection on the board has become damaged in some way. The board itself is working as I have programmed a few of the examples, such as the "FG4618 Real Time Clock" with no problems.

Thanks for all the help,

Mike

Bart Oegema said:

What software are you using to capture the serial with the PC? Verify that you are consistent with the settings - you probably don't want flow control or parity, and a single stop bit. What did you find with the oscilloscope? Was the data output clear, or was it garbled? If the output is clear, there's probably an issue with the PC handling the output correctly.

I have been using various programs, including Brays Terminal, Termite, and the terminal in Code Composer Essentials v3. I also used Hyperterminal for a while. My settings have been consistent - no flow control or parity, and a single stop bit. I've tried out various bit rates, including 9600 and 4800, with no obvious distinction.

The output of the oscilloscope was clear, and I verified that it corresponded to the binary value of the particular ASCII character being sent. It was also going at the desired bit rate.

I also verified that data being sent from the PC was being received on the UCARXBUF register of the MSP430FG4618, using the register view in CCE.

It would make sense that it would be an issue with the PC now, considering the evidence. I've also observed another aspect of the transmission. When the connection is first initiated using software, a number of characters are displayed, but then the transmission appears to be blocked even though the connection remains. By disconnecting and connecting again (in the terminal software), another few characters are displayed.

The way this appears to be happening makes it seem like the computer is allowing data through from the receive pin of the RS232 for a very short time period after a connection has been established and then blocking any further data. It's as if some flow control is in place, even though the no flow control option was specified each time.