cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in Cube F4 HAL_UART_IRQHandler

Posted on December 15, 2014 at 23:26

* @file    stm32f4xx_hal_uart.c  

* @author  MCD Application Team

* @version V1.1.0

* @date    19-June-2014

There 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-interrupt
7 REPLIES 7
Posted on December 16, 2014 at 00:10

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.

stst9193
Associate II
Posted on December 16, 2014 at 08:42

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.

Regards

hbarta2
Associate III
Posted on December 17, 2014 at 17:24

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.
Posted on January 12, 2015 at 16:34

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.

pdu-fr
Associate II
Posted on January 13, 2015 at 20:39

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.

kotwal
Associate II
Posted on January 19, 2015 at 22:56

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. 

-Tom

admin23
Associate II
Posted on November 11, 2015 at 19:02

Did you solve this bug?

I have the same problem but i don't know if it is or not.

thanks