Posted on January 25, 2018 at 11:21Hi,
i found a bug in the HAL library for STM32L053C8Tx, when using UART with DMA. STMCube says its version STM32Cube FW_L0 V1.10.0
It seems that, in HAL_UART_IRQHandler the DMA should be reset when an Error occurs.
In a first step, the DMA request is disabled with CLEAR_BIT(huart->Instance->CR3, USART_CR3_DMAR); in line 1704 in stm32l0xx_har_uart.c
The program then jumps to HAL_DMA_Abort_IT at line 487 in stm32l0xx_hal_dma.c to reset the DMA.
It will only reset the DMA if hdma->State is HAL_DMA_STATE_BUSY. In my case, hdma->State is HAL_DMA_STATE_HALF_READY, which in my eyes qualifies as busy, but of course HAL_DMA_Abort_IT returns with HAL_ERROR, because its not HAL_DMA_STATE_BUSY. Thats why the DMA never gets reset, the Lock is still locked and state is still HAL_DMA_STATE_HALF_READY.
This results in very strange behaviour when using DMA after the error, as Rxcount, destination and source can't be changed. Calls to HAL_UART_DMAStop or HAL_UART_Abort won't do the trick, as USART_CR3_DMAR was cleared, making the program assume that DMA was properly reset.
I also use an STM32F0, which in my understanding has a slightly different HAL lib. In my STM32F0 project i couldn't find HAL_DMA_STATE_HALF_READY. It seems to me like that state was removed from some part of the HAL universe, but surely it was not done properly.
I hope this error gets fixed, either by eliminating HAL_DMA_STATE_HALF_READY or allowing HAL_DMA_Abort_IT to abort with state = HAL_DMA_STATE_HALF_READY.
Also i think it problematic to rely on USART_CR3_DMAR only to check if any DMA changes are needed, though there are many other variables that need to be changed to make the HAL lib work..
Maybe
LE_SAINT.Erwan
‌ or any member of the HAL development team can help here?
Thanks,
Till
null
