cancel
Showing results for 
Search instead for 
Did you mean: 

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

KOkun.1048
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

View solution in original post

15 REPLIES 15
TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".
KOkun.1048
Associate III

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
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".
KOkun.1048
Associate III
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
Associate III

At line 3007, the driver accesses as 16bit.

KOkun.1048
Associate III

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

TDK
Guru

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

If you feel a post has answered your question, please click "Accept as Solution".
Imen.D
ST Employee

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

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen