UART interface with MSP

That is a very common problem. It can usually be solved by carefully read your code three time from the beginning to the end. After that, try to explain it line by line to your dog. Before your dog understands what you are talking about, you usually can discover the mistakes.

If you ask me, and I am not your dog, I cannot say that your line #53 has a mistake. I have no idea what your line #53 says. (Nor any other line.)

What I believe old_cow_yellow is trying to say is that you should specify the problem better when posting to the forum. First, double check your code. If it looks OK to you, but it's still not working - post specific questions and add relevant code as reference. There is plenty of helping hands out here, but we need some information before we can help you out.

Edit: I strongly encourage everyone to do the following before posting a new thread:
1. Think through: What are the specifics of the issue you are facing.
2. Search the E2E community using keywords that are relevant for your problem. A lot of problems have already been solved on E2E!
3. If you couldn't find the solution to your problem in any existing posts, read Asking a Question on the Learn E2E and then post your question.

Best regards,
ABO 

Do you read the incoming serial data bit by bit from the I/O pin? Or do you use a hardware UART which does all the timing and bit collecting for you and presents you ready-made bytes from the RX stream?

However, without knowing what you do, nobody can tell you what you might do wrong.

I am sorry. I should have stated my problem in detail.

I am to receive continuous data from a GPS module which runs at 4800 baud TTL levels. I have set my 10.5 pin as peripheral function (RX of UART) and also set it in the IN direction. In my interrupt vector, I have called a function to read the RX Buffer and store it in an array of a specific size. This is how the function looks like

void USARTrecvbuffer(char * buffer, int len)
{
int rlen=0;
int timeout;
while(rlen<len)
{
timeout=0;
UCA3IFG &= ~UCRXIFG;
while(!(UCA3IFG & UCRXIFG)&& (timeout++ < timeout0)){}
if(timeout>=timeout0) break;
buffer[rlen]=UCA3RXBUF;
rlen++;
}

}

where timeout0 = 2* (F_SMCLK/baud)

This program either runs for a very long time with no results, or it stores junk values.

Is there any other method by which we can receive data for a particular amount of time? Or any modification in my function?

Thankyou 

From my answer in out private conversation:

Well, your timeout depends on code execution speed.
It is better to use a timer for this kind of operation:

• define a global volatile variable timeout
• setup the timer to make an interrupt, say, every ms.
• in the timer ISR, you decrement timeout as long as it is >0.

In your main code, set timeout to the desired timeout in ms, then loop until timeout is 0.

while(rlen<len)
{
  timeout = timeout0;
  UCA3IFG &= ~UCA3IFG;
  while(!(UCA3IFG & UCRXIFG) && timeout);
  if(!timeout) break;
  buffer[rlen++]=UCA3RXBUF;
}

However, your code does not use interrupts (other than manually checking the IFG bit), so what do you mean with 'in my interrupt vector, I have called a function' ?You should not call a function that has an indeterminate execution length from inside an ISR, if that's what you mean. ISRs are fast-in interrupts of the currently running program, and should be fast-out too. Also, while you are inside an ISR, no other interrupt can be handled.So doing something inside an ISR that waits for something is a no-go! ISRs are to reacht on the fact that somethign has just happened an dneeds immediate attention, and not to wait for something that will happen (or not).

From your other posts, you appear to be using the MSP430F5438 (or F5438A) device.

Have you put together a very simple example to ensure communication between the MSP430F5438 USCI interface and your GPS subsystem is functioning before integrating into a larger application code?

I would suggest taking one of the MSP430F5438 code examples as a quick starting point and verify this communication.  These code examples are found on the MSP430F5438A Product Folder in the Software & Development Tools section.  Perhaps start with MSP430x54xA_uscia0_uart_03.c and tailor to your setup, including baud rate, etc.  This example performs a loopback, so you will want to remove that functionality and simply write the USCI Received bytes into a buffer to ensure that you are able to collect the NMEA sentences.  This example illustrates using the interrupt service routine that Jens-Michael Gross mentioned rather than polling.