USART1 Interrupt

[pranathi1091]

Posted on December 14, 2012 at 08:30

HEllo ALL,

I am using stm32f2 and i have programmed USART which is interfaced to GPS. The problem i m facing is, When USARt is enabled, i always get the my RXNE interrupt set, since GPS sends data continuosly and control jumps to this vector address(m using stm32f2xx_it.c). and m clearing the interrupt bit once i receive. Since m getting the interrupt all other things are getting affeected and i am unable to get control on GPS module.I just want a specifeid data from GPS. Could anyone let me know How can i handle this interrupt and get data i want? Thanks Pranathi #stm32-usart

[frankmeyer9]

Posted on December 14, 2012 at 09:18

That is the nature of such GPS modules...

First, most modules come with some configuration software, running on a PC. Check the vendor's website, too. Using this software, you can configure the baudrate, the mode (proprietary/NMEA), the sentences sent, and the update rate. In your interrupt handler, you need to pre-parse the received data, to detect the start and end. NMEA sentences always start with '$', and end with Newline. Once you have a buffer filled that way, you have received a valid sentence. You will need to copy that sentence to another buffer, or the next receive interrupt is going to overwrite it. I suggest to parse the sentence outside of the interrupt. You only need to check the first 5 chars following the $ for the sentence type , and possibly the sattelite status information (valid/invalid). All in all, it is a good programming exercise.

[pranathi1091]

Posted on December 14, 2012 at 09:53

Thanks for the reply.

The problem is I am not able to control GPS, bcs once i USART is enabled i have to send control commands to receive the data i want. Since the interrupt is occuring as soon USART is enabled, i receive interrupt and data floods.Here is my Interrupt handler. Please suggest me if anything else needs to be done void USART1_IRQHandler(void) { uint8_t ucArguments[MAX_ARGS][MAX_ARG_LENGTH];

  static int tx_index = 0;

  static int rx_index = 0;   uint8_t g_ucGpsRxDataBuf[60];   if (USART_GetITStatus(USART1, USART_IT_TXE) != RESET)   {    USART_ClearITPendingBit(USART1,USART_IT_TXE);     USART_SendData(USART1, g_ucGpsCommand[tx_index++]);     if (tx_index >= (sizeof(g_ucGpsCommand) - 1))       tx_index = 0;   }     if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)    {    USART_ClearITPendingBit(USART1,USART_IT_RXNE);    g_ucGpsRxData[rx_index++] = USART_ReceiveData(USART1);    g_ucGpsRxDataBuf[rx_index++]= g_ucGpsRxData[rx_index++];    ParseOutput(g_ucGpsRxDataBuf,',');    Delay(100);    Display(g_ucGpsRxDataBuf[i]);        if (rx_index >= (sizeof(g_ucGpsRxData) - 1))      rx_index = 0;   }  }   } }

[frankmeyer9]

Posted on December 14, 2012 at 11:05

I can't see a big problem here. The UART can (and does) work in full duplex mode, meaning it can send and receive at the same time. If you send this AT commands interrupt driven, you get UART interrupts. You need to handle sending and receiving separate, and depending on your state machine.

What is standing out in your code: 1. uint8_t ucArguments[MAX_ARGS][MAX_ARG_LENGTH]; uint8_t g_ucGpsRxDataBuf[60]; You are very promiscuously define local variables in the interrupt handler. Are you aware that this arrays are gone after each interrupt ? 2.   ParseOutput(g_ucGpsRxDataBuf,',');    Delay(100);    Display(g_ucGpsRxDataBuf[i]); Not sure what this calls involve, but I would avoid doing delays inside of interrupt routines, and other expensive function calls. That is better done by double buffering, and transfering that expensive calls to your main loop.

[pranathi1091]

Posted on December 14, 2012 at 12:45 I have moved those local variables, The Parse is for extracting the data and next is just a display function. I could resolve that interrupt issue by disabling it till all my trasnmissions are completed . So i can transmit now. But GPS doesnt send valid data it send just $ cahracter

[frankmeyer9]

Posted on December 14, 2012 at 13:39

So i can transmit now. But GPS doesnt send valid data it send just $ cahracter

I suggest to check with a terminal program what the GPS module actually sends. But I would be rather surprised if the GPS module actually sends such corrupted data. By experience, especially including my own, I can state that in most cases the problem sits in front of the keyboard ...

[Tesla DeLorean]

Posted on December 14, 2012 at 15:32

To be honest is doesn't look like you have the character processing figured out.

Suggest perhaps that you accumulate a line, between '$' and <CR><LF> pair, and then parse that as a whole, with a NUL character on the end so you don't break any string functions. What GPS receiver needs to be sent a continuous stream of commands?