UART receive interrupt stops triggering after several hours of successful receive

问题

I am using STM32f4 discovery board connected with xbee to receive temperature data from remote temperature sensor. Code used is CMIS UART example code. I will receive packet data, 1 byte at a time. In other words UART receive interrupt will be called whenever each byte receives. Once I gets the complete packet I will copy the temperature data. My UART callback function works without any issue. But after several hours, UART receive interrupt stops working and UART cannot receive anything. However UART transmission still works. I am using UART1 with baud rate 115200. I have set UART interrupt priority as 0 and no other interrupt shares this priority. All other interrupt priority are lower than UART. Can any one please tell me why UART interrupt stops triggering?

#define PACKET_DELIMETER 0x7E

uint8_t g_frame_ok=0; //flag to indicate complete packet received
uint8_t g_index_of_aoBuf=0; //Index of receive buffer
uint8_t g_aoBuf_of_xbee[100]={0};//Receive Buffer
uint8_t r_byte=0; //Receiving byte 

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *allUartHandle)
{
 __HAL_UART_FLUSH_DRREGISTER(allUartHandle); 

 if(HAL_UART_Receive_IT(allUartHandle, (uint8_t *)&r_byte, 1) == HAL_OK) //Interrupt occurs when each byte arrives
 {
    if(r_byte==PACKET_DELIMETER)
    {
        //start receiving packet
    }
    if( g_index_of_aoBuf>=g_aoBuf_of_xbee[2]+4)
    {
        g_frame_ok=1;
        BSP_LED_On(LED4);
    }           
   }
 }

回答1:

I never used the API you mention, so I may be wrong, but here are a few things I noticed after taking a look :

HAL_UART_RxCpltCallback is not an UART interrupt. It's a callback from the HAL subsystem that will be called when a receive request you issued is completed. This means it will only be called some time after you issue a receive request. You don't have access to the UART interrupt, and you shouldn't try to mess with it if you use the HAL layer.

About this, HAL_UART_Receive_IT is actually a function that will issue a receive request. It will always return immediately, and it will never receive anything. This means the data in the receive buffer just after the call is not valid. Once you issued the request, HAL_UART_RxCpltCallback will be called anytime after, when the receive is complete. Only at this point the data in the buffer will be valid. To retrieve the data you can use the same variable from the HAL_UART_Receive_IT, but the data buffer will also be available through (UART_HandleTypeDef*)->pRxBuffPtr from the callback parameter.

I think it's OK to call HAL_UART_Receive_IT again in the callback, but it's probably better to do it at the end.

Also, what is __HAL_UART_FLUSH_DRREGISTER used for ? To me it looks like it will do more harm than good.

回答2:

Variables that are shared between a callback function and the rest of the program must be declared as volatile, to prevent the compiler from optimizing the code incorrectly.

You also have to ensure that writes and reads to such variables are atomic, or alternatively protect them with a semaphore. Otherwise you may get race condition bugs.

Either or both of these two classic bugs could cause the problem you describe: both tend to cause intermittent, unexpected behavior which is hard to re-produce.

Also, if your CPU allows it, set a breakpoint which triggers on write access to the interrupt enable register and check the trace.

来源：https://stackoverflow.com/questions/31156982/uart-receive-interrupt-stops-triggering-after-several-hours-of-successful-receiv

标签

embedded

stm32f4discovery

cmsis