Estoy usando la placa de descubrimiento STM32f4 conectada con xbee para recibir datos de temperatura del sensor de temperatura remoto. El código utilizado es el código de ejemplo CMIS UART. Recibiré paquetes de datos, 1 byte a la vez. En otras palabras, se llamará a la interrupción de recepción de UART cada vez que se reciba cada byte. Una vez que obtenga el paquete completo, copiaré los datos de temperatura. La función de devolución de llamada de mi UART funciona sin ningún problema. Pero después de varias horas, la interrupción de recepción de UART deja de funcionar y UART no puede recibir nada. Sin embargo, la transmisión UART todavía funciona. Estoy usando UART1 con una velocidad de transmisión de 115200. Establecí la prioridad de interrupción de UART en 0 y ninguna otra interrupción comparte esta prioridad. Todas las demás prioridades de interrupción son más bajas que UART. ¿Alguien puede decirme por qué la interrupción de UART deja de activarse?
#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); } } }Nunca usé la API que mencionas, así que puedo estar equivocado, pero aquí hay algunas cosas que noté después de echar un vistazo:
HAL_UART_RxCpltCallback no es una interrupción de UART. Es una devolución de llamada del subsistema HAL que se llamará cuando se complete una solicitud de recepción que emitiste. Esto significa que solo se llamará algún tiempo después de que emita una solicitud de recepción. No tiene acceso a la interrupción UART, y no debe tratar de meterse con ella si usa la capa HAL.
Acerca de esto, HAL_UART_Receive_IT es en realidad una función que emitirá una solicitud de recepción. Siempre regresará inmediatamente, y nunca recibirá nada. Esto significa que los datos en el búfer de recepción justo después de la llamada no son válidos. Una vez que haya emitido la solicitud, se llamará a HAL_UART_RxCpltCallback en cualquier momento posterior, cuando se complete la recepción. Solo en este punto los datos en el búfer serán válidos. Para recuperar los datos, puede usar la misma variable de HAL_UART_Receive_IT , pero el búfer de datos también estará disponible a través (UART_HandleTypeDef*)->pRxBuffPtr del parámetro de devolución de llamada.
Creo que está bien volver a llamar a HAL_UART_Receive_IT en la devolución de llamada, pero probablemente sea mejor hacerlo al final.
Además, ¿para qué se usa __HAL_UART_FLUSH_DRREGISTER ? A mí me parece que hará más mal que bien.
Las variables que se comparten entre una función de devolución de llamada y el resto del programa deben declararse como volátiles para evitar que el compilador optimice el código de forma incorrecta.
También debe asegurarse de que las escrituras y lecturas de dichas variables sean atómicas o, alternativamente, protegerlas con un semáforo. De lo contrario, puede obtener errores de condición de carrera.
Cualquiera de estos dos errores clásicos o ambos podrían causar el problema que describe: ambos tienden a causar un comportamiento intermitente e inesperado que es difícil de reproducir.
Además, si su CPU lo permite, establezca un punto de interrupción que se active en el acceso de escritura al registro de habilitación de interrupción y verifique el seguimiento.