HAL UART Issues

[igiona-scewo]

Hi,

I had to recently work on an application that makes use of the UART, and encountered some issues in the HAL (most recent version provided by CubeMX):

1) Hal bug?

Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_uart.c, Line 3825:3831

if (!(IS_LPUART_INSTANCE(huart->Instance))) {
    /* Check that USART RTOEN bit is set */
    if (READ_BIT(huart->Instance->CR2, USART_CR2_RTOEN) != 0U) {
        /* Enable the UART Receiver Timeout Interrupt */
        ATOMIC_CLEAR_BIT(huart->Instance->CR1, USART_CR1_RTOIE);
    }
}

According to the reference manual, USART_CR1_RTOIE must be set in CR1 in order to enable the interrupt, here it's cleared.

2) If one performs a HAL_UART_Transmit() and in case an error interrupt is fired on the peripheral tries to  call HAL_UART_Abort(), a buffer overflow can occur and undesired data is pushed the UART-TX.

In the abort function "huart->TxXferCount" is set to 0, whereas in the transmit loop the HAL directly decrements that shared variable.

A race condition can occur when the Abort call comes just before the decrement in the Transmit loop, causing the variable to underflow and therefore the loop to run for up to 64k times accessing the user-buffer very likely out of range.

Maybe the Abort function is not meant to be called in interrupt context, non the less the blocking Transmit function is poorly designed and can be improved to avoid the buffer overrun in the first place.

[Pavel A. · Accepted solution]

In the current HAL G4 version the line numbers have moved - do you mean this place?

https://github.com/STMicroelectronics/stm32g4xx-hal-driver/blob/69accade0a117e66abbd6620ac95ebbc3de0f4d8/Src/stm32g4xx_hal_uart.c#L4235

In some places the comment is wrong, the intent is to clear the RTO interrupt.

(2) Function HAL_UART_Transmit() is not meant to enable (and receive) error interrupts. 

For complex use cases consider writing your own driver code, using the "HAL" source as learning material.

[igiona-scewo]

Hi Pavel, thank you for the quick reply.

1) Yes, is that one. I see, the one (code) or the other (comment) is surely off :)
I didn't realized the code was on GH, I would have opened the issue there :)

2) I see, thank you for the explanation.

>using the "HAL" source as learning material

Wow, that's a statement. I did not you consider your HAL learning material... good to know.
I think this makes the Rust adoption decision even easier for us :D

Thank you for your support.

[Pavel A.]

@igiona-scewo About Rust, just one caution: it is the new Microsoft's darling. When you see that Microsoft likes and promotes something - drop it and run in the opposite direction!