Posted on June 08, 2017 at 12:30
In my application, I use 8 data bits and odd parity in serial communication (so, it is a 9 bit wordlength).
During reception, I found that a variable which was contiguous, but outside the receive buffer, was being overwritten by the HAL serial driver going beyond te end of my serial buffer, due to the following code found in STM32F2XX_HAL_UART.C from line 2372:
static HAL_StatusTypeDef UART_Receive_IT(UART_HandleTypeDef *huart)
{
uint16_t* tmp;
/* Check that a Rx process is ongoing */
if(huart->RxState == HAL_UART_STATE_BUSY_RX)
{
if(huart->Init.WordLength == UART_WORDLENGTH_9B)
{
tmp = (uint16_t*) huart->pRxBuffPtr;
if(huart->Init.Parity == UART_PARITY_NONE)
{
*tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
huart->pRxBuffPtr += 2;
}
else
{
*tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF); <<<---ERROR HERE----
huart->pRxBuffPtr += 1;
}
}
else
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�? {
if(huart->Init.Parity == UART_PARITY_NONE)
{
*huart->pRxBuffPtr++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
}
else
{
*huart->pRxBuffPtr++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
}
}
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
the badline is the marked one: it should completely avoid to treat the receive buffer as 16 bit, zeroing the upper byte, then advancing the pointer by one.
It simply should access the receive buffer at the byte level, just as the case in which the wordlength is not 9 bit.
This does hot cause harm if the receive buffer is always oversized, but anyway it slows down the cpu forcing a 16 bit misaligned access.
Is this forum the right place to signal bugs about hal drivers?
Best Regards,
--Vito.
