cancel
Showing results for 
Search instead for 
Did you mean: 

Missing out byte while receiving data on UART

newbie_stm32
Associate III

Hi Community,

I am working in a freeRTOS environment where one of the threads parses the serial data from the UART. A protocol is defined to decode the hex stream received from another device. HAL_UART_RxCpltCallback is configured to receive one byte at a time and is filled in an array that houses a sufficient amount of data (no overflow). But sometimes a byte is getting missed out which is a mid byte.

To troubleshoot this issue set the RX FIFO threshold to generate an interrupt if the FIFO is full. However, whenever a byte is missed it does not trigger a HAL_UARTEx_RxFifoFullCallback (still figuring out how to get this work no interrupt is being generated even if I set the threshold to UART_RXFIFO_THRESHOLD_1_8).

Core: STM32G491

Clock: 170MHz (HSE + PLL)

Here is the program flow:

 

uint8_t rx_data;

for (;;)
{
  /* This is added for the synchronization to disable ISR being called */
  HAL_UART_AbortReceive(&huart1);

  /* 1. Check for the stream ending \r\n
   * 2. Decode and process the byte stream
   * 3. Reset index (index = 0)
   */

  /* This is added for the synchronization */
  HAL_UART_Receive_IT(&huart1, &rx_data, sizeof(rx_data));
  
  osDelay(1);
}

 

ISR

 

void HAL_UART_RxCpltCallback (UART_HandleTypeDef * huart)
{
  rx_buffer[index++] = rx_data;
  HAL_UART_Receive_IT(&huart1, &rx_data, sizeof(rx_data));
}

 

2 REPLIES 2
TDK
Guru

> HAL_UART_AbortReceive

This shouldn't be called from the main loop. If you abort something already in progress, it makes sense that bytes are being lost.

Also, calling HAL_UART_Receive_IT repeatedly is not proper.

 

What you should be doing is the following:

  • Call HAL_UART_Receive_IT once within the main thread to start reception.
  • Call HAL_UART_Receive_IT once within HAL_UART_RxCpltCallback (you're doing this).
If you feel a post has answered your question, please click "Accept as Solution".
newbie_stm32
Associate III

Hi @TDK, thanks for pointing out misconception.