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.