2014-12-15 02:26 PM
* @file stm32f4xx_hal_uart.c
* @author MCD Application Team* @version V1.1.0* @date 19-June-2014There is a problem with HAL_UART_IRQHandler where received data will be lost.
If you have a set of characters being transmitted while data is being received (such as if you have a port wired for loopback (Tx wired to Rx)), the received data will cause an overrun error if they happen to come in while the handler is transmitting the last character of the data buffer.
On a transmitter empty interrupt, HAL_UART_IRQHandler will call UART_Transmit_IT to send the next character. If the next character is the last character in the buffer, this routine disables transmitter empty interrupts then uses the following code to wait for the transmitter to drain the last character:
if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_TC, RESET, UART_TIMEOUT_VALUE) != HAL_OK)
{
return HAL_TIMEOUT;
}
The timeout on this code is 22000 milliseconds or 22 seconds(!), but the typical time would be 1 character time plus overhead.If any characters are received while this code block is being executed, the RXNE interrupts (or any others) are not fielded, since we are still in the interrupt routine and it is busy waiting for the transmitter to drain.This problem happens independent of the number of characters being transmitted or the baud rate.So, Cube authors, can you suggest a workaround? #cube-hal-uart-interrupt2014-12-15 03:10 PM
I found a discussion of this same bug on the L0 processors dated 12/09/2014 11:05 by Heisenberg, but the fix code is incompatible with the F4 HAL.
2014-12-15 11:42 PM
Hello Andrei,
There are a lot of wait loops (wiat on flag until something happens) in HAL driver. The problem is not only with UART. They are all potential time bombs! Thus I would rather ask ST when we will get a new version of HAL drivers without this kind of shortcomings. Regards2014-12-17 08:24 AM
I found this thread searching on ''HAL UART overrun'' (which will be the subject for another post.)
As to the solution, since we have source for the HAL libraries, why not make the necessary modifications. I really hope that 22s is a mistake for busy waiting in an ISR and I assume a more appropriate time could be substituted.2015-01-12 07:34 AM
Hi,
We are aware of this limitation, and have already listed within the STM32CubeF4 HAL bugs tracker. Keep an eye out for the next update! Thanks for the report.Regards,Heisenberg.2015-01-13 11:39 AM
Hey,
I had to suppress those lines of code from the HAL source code (uart.c). My application use about 100% of the Tx bandwidth. ORE raises all the time. Hope the fix will come soon !Bye,Patrick.2015-01-19 01:56 PM
I ran into this problem too, so I just wanted to say thanks for pointing out the cause of the problem, and to add another voice to those that are waiting for a bug fix.
In our application we have control over the device at the other end of the uart, so our workaround is to adjust the protocol to make sure we never have to transmit and receive at the same time. -Tom2015-11-11 10:02 AM
Did you solve this bug?
I have the same problem but i don't know if it is or not. thanks