On RX Framing error, UART_DMAAbortOnError can corrupts ongoing TX transfer resulting in 65536 bytes transfered. HAL bug ?

[NSAUG.1]

Hi,

I use STM32Cube_FW_WB_V1.12.1 on a STM32WB55, with generated init code and HAL functions.

I have setup a circular DMA for RX of UART1 and use HAL_UART_Transmit() when I need to send data.

I'm communicating with a device (GPS module) that can be configured at two different baud rates, so I have written code to try to talk to it alternatively at both baud rates until it responds something that the UART understands.

The problem is that upon raising a Frame Error on RX, HAL_UART_IRQHandler calls HAL_DMA_Abort_IT which in turn calls UART_DMAAbortOnError, which is implemented as below :

/**
  * @brief  DMA UART communication abort callback, when initiated by HAL services on Error
  *         (To be called at end of DMA Abort procedure following error occurrence).
  * @param  hdma DMA handle.
  * @retval None
  */
static void UART_DMAAbortOnError(DMA_HandleTypeDef *hdma)
{
  UART_HandleTypeDef *huart = (UART_HandleTypeDef *)(hdma->Parent);
  huart->RxXferCount = 0U;
  huart->TxXferCount = 0U;
 
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
  /*Call registered error callback*/
  huart->ErrorCallback(huart);
#else
  /*Call legacy weak error callback*/
  HAL_UART_ErrorCallback(huart);
#endif /* USE_HAL_UART_REGISTER_CALLBACKS */
}

As you can see, TxXferCount is set to zero, evn though the original error only concerns RX...

And when this happens while HAL_UART_Transmit is ongoing, specifically in this snippet of that function :

while (huart->TxXferCount > 0U)
    {
      if (UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_TXE, RESET, tickstart, Timeout) != HAL_OK)
      {
        return HAL_TIMEOUT;
      }
      if (pdata8bits == NULL)
      {
        huart->Instance->TDR = (uint16_t)(*pdata16bits & 0x01FFU);
        pdata16bits++;
      }
      else
      {
        huart->Instance->TDR = (uint8_t)(*pdata8bits & 0xFFU);
        pdata8bits++;
      }
      huart->TxXferCount--;
    }

the result is TxXferCount going to zero just before being decremented, so it wraps around to 65536 (TxXferCount is volatile).

This obviously leads to a very wrong result of having about 1/3rd of the RAM of my chip transmitted.

This bug looks like a HAL bug to me.

The behavior I would have though normal here would have been to only reset the RxXferCount when the error concerns only RX.

Best,

Nicolas