stm32l4xx_hal_uart.c: UART_WaitOnFlagUntilTimeout() does not clear ORE

[Slove.1]

I am using STM32CubeIDE 1.7.0 with a NUCLEO-L432KC (STM32L432K). I wanted to add support for stdio via the VCP UART and successfully implemented __io_putchar(). However, I struggle(d) to get __io_getchar() to work by using HAL_UART_Receive() (because there is another bug - presumably in the uclibc shipped by ST). Instead I overload getchar() directly. That works a bit but only if data is sent very slowly to the MCU. If it is too fast, the receive function hangs:

The symptom is that UART_WaitOnFlagUntilTimeout() called by the receive function does not return (till the timeout) if an overrun occurs. If there are no overruns the receive (and the getchar() using it) works fine. If there is an overrun, then the timeout function must clear the ORE flag to have any chance of noticing further received data but it doesn't.

I have added the following directly before the test (and reset) for the RTOF bit:

@@ -3535,6 +3536,8 @@ HAL_StatusTypeDef UART_WaitOnFlagUntilTimeout(UART_HandleTypeDef *huart, uint32_
 
       if (READ_BIT(huart->Instance->CR1, USART_CR1_RE) != 0U)
       {
+        if (__HAL_UART_GET_FLAG(huart, UART_FLAG_ORE) == SET)
+          __HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_OREF);
         if (__HAL_UART_GET_FLAG(huart, UART_FLAG_RTOF) == SET)
         {
           /* Clear Receiver Timeout flag*/

I have only done some preliminary tests but this seems to have fixed the hangs I've been noticing.

PS: Please make the source code of the newlib shipped with stm32cubeide available. Not being able to see what's going on between the HAL and my application dramatically reduces my effectiveness. The library also seems to be very outdated and thus many of the bugs are already known but hidden in the binaries. :(

[SShau.1]

I am facing the exact same issue for the HAL_UART_Transmit() function instead. It was working until yesterday when I was using 1.6.1. The moment I upgraded to 1.7.0 it has stopped working. Please let me know if you have an answer for this.

[scottalexgray]

So I have recently had a similar issue. It seemed to fix itself when I disabled overrun in UART config in CubeMX (or in the init code)

[cw1a]

Thanks for your reply! How did you disable the overrun in the UART?