[BUG] STM32{F1,F2,F4,L1}xx_HAL_driver for UART accesses out of user specified buffer.

[KOkun.1048]

When we use UART as DATA 8bits with parity, STM32F4xx_HAL_driver for UART accesses one byte beyond the specified buffer. Could you please confirm attached patch?

In stm32f4xx_hal_uart.c , there are other similar problems.

[TDK]

I'm not seeing where this accesses any more than exactly one byte in the given scenario. Perhaps explain more why you think what you do.

[KOkun.1048]

The driver accesses buffer as uint16_t, if the setting is data 8bits with

parity. So, when we use for example HAL_UART_receive(), the driver write “0x00�?

to the next last byte. “0x00�? is derived bit mask “0x00ff�?.

[TDK]

pRxBuffPtr is of type uint8_t *. So the statement *huart->pRxBuffPtr = (uint8_t) tmp only accesses a single byte.

It only accesses it as a uint16_t if parity is none and wordlength is 9 bits.

Edit: I see now you're referring to the before-diff statements and not the after-diff statements. I agree with your assessment.

[KOkun.1048]

2984 /**
2985 * @brief Receives an amount of data in non blocking mode
2986 * @param huart Pointer to a UART_HandleTypeDef structure that contains
2987 * the configuration information for the specified UART module.
2988 * @retval HAL status
2989 */
2990 static HAL_StatusTypeDef UART_Receive_IT(UART_HandleTypeDef *huart)
2991 {
2992 uint16_t *tmp;
2993 
2994 /* Check that a Rx process is ongoing */
2995 if (huart->RxState == HAL_UART_STATE_BUSY_RX)
2996 {
2997 if (huart->Init.WordLength == UART_WORDLENGTH_9B)
2998 {
2999 tmp = (uint16_t *) huart->pRxBuffPtr;
3000 if (huart->Init.Parity == UART_PARITY_NONE)
3001 {
3002 *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
3003 huart->pRxBuffPtr += 2U;
3004 }
3005 else
3006 {
3007 *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF);
3008 huart->pRxBuffPtr += 1U;
3009 }
3010 }
3011 else
3012 {
3013 if (huart->Init.Parity == UART_PARITY_NONE)
3014 {
3015 *huart->pRxBuffPtr++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
3016 }
3017 else
3018 {
3019 *huart->pRxBuffPtr++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
3020 }
3021 }
3022

https://github.com/STMicroelectronics/STM32CubeF4/blob/a86ecaa2fb63029596ba7dabadab2d9c2c139560/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_uart.c#L2990

Please refer to the avobe.

This code is stm32f4xx_hal_uart.c in version 1.25.0.​

 When we use DATA 8bits with parity, Init.WordLength is UART_WORDLENGTH_9B.

[KOkun.1048]

At line 3007, the driver accesses as 16bit.

[KOkun.1048]

The same code exists in STM32F1xx, STM32F2xx and STM32L1xx

https://github.com/STMicroelectronics/STM32CubeF1/blob/441b2cbdc25aa50437a59c4bffe22b88e78942c9/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_uart.c#L2992

https://github.com/STMicroelectronics/STM32CubeF2/blob/42fc8bf966c04ef814bb0620dcd3e036e038b4a2/Drivers/STM32F2xx_HAL_Driver/Src/stm32f2xx_hal_uart.c#L2984

https://github.com/STMicroelectronics/STM32CubeL1/blob/910c24274e58b6c179894706d16cbc5162ced586/Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_hal_uart.c#L2965

But, other MCU series have other UART hard logic, so the same codes don't exist.

[KOkun.1048]

My attached file is partial solution for this issue. Other accesses exist in this driver.

[TDK]

This bug has been present since at least v1.21.0, which is the oldest firmware I have on my computer.

[Imen.D]

Hello,

I will review this issue and come back to you with update.

Thank your for your contribution and the issue reporting.

Best Regards,

Imen

[KOkun.1048]

Hi Imen,

Thank you for your response! I look forward to good news.

​

[Imen.D]

This issue will be fixed in the coming release of Cube firmware package for all impacted series.