Wrong behaviour on HAL_UART_DMAStop function on multiple series of chips' hal library

[Headcrabed]

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum

Describe the set-up Board tested: NUCLEO-H743ZI2,NUCLEO-L432KC,NUCLEO-G431KB SW Environment: STM32Cubeide 1.9.0/1.8.0/1.6.1(all with newest version of hal library supported)

Describe the bug When UART DMA and interrupt for that DMA is enabled, HAL_UART_DMAStop() function won't reset status flag of uart peripheral correctly, since huart->Instance->CR3's USART_CR3_DMAT bit has been cleared by the interrupt. However, enable the uart peripheral's interrupt at the same time or only enable uart interrupt or disable both interrupts in cube would not cause this bug. This bug might also affect HAL_UART_DMAPause(), but I'm not sure. This bug affects multiple series of hal driver, including L4,G4 and H7 series(I can only test these, but more series could be affected), and seems doesn't exist on F1/F4 series(not sure).

How To Reproduce

1. Enable an uart peripheral in cube, enable tx dma(normal mode), enable dma interrupt but do not enable uart interrupt.
2. Use HAL_UART_Transmit_DMA to send some thing in a while block.
3. Set a HAL_Delay to wait for transfer complete.
4. Use HAL_UART_DMAStop to stop dma.
5. You'll see data that should be sent would only send once, however it should be sent forever.

[ASELSTM]

Hi @Headcrabed,

Would you please share the whole project you have used to reproduce the issue in order to allow a better analysis of the problem.

With regards,

[Headcrabed]

Hi @Headcrabed,

Would you please share the whole project you have used to reproduce the issue in order to allow a better analysis of the problem.

With regards,

@ASELSTM I've just made an example project here:https://drive.google.com/file/d/1xbPPCaNMcVSYGVPaYtCkKbJ-nA0oQysw/view?usp=sharing Created using STM32CubeIDE v1.9.0 and board used is NUCLEO-G474RE Remapped on-board stlink v3's vcp to usart2(default settings was lpuart1)

[Headcrabed]

@ASELSTM have you checked the project I 've uploaded?

[ASELSTM]

Hi @Headcrabed,

First, excuse this late answer. The UART interrupts should be enable even if you are using DMA.

The XferCpltCallback indicates that the DMA has finished transferring the last data in the TDR register. Hence, when the DMA callback is called the data has not yet been sent that's why the TCIE is enabled to get the TC interruption at the end of the transfer.

https://github.com/STMicroelectronics/STM32CubeH7/blob/af967c5899d8f5c11eff4a12d647d11b823986a4/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_uart.c#L2503-L2508

The gstate will thus be reset to HAL_UART_STATE_READY once TC interrupt is triggered.

https://github.com/STMicroelectronics/STM32CubeH7/blob/af967c5899d8f5c11eff4a12d647d11b823986a4/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_uart.c#L4187-L4188

You can fix the issue by enabling the USART2 interrupts as shown in the code snippet below, the data is thus be sent continuously.

  HAL_NVIC_SetPriority(USART2_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(USART2_IRQn);

In the other hand, please note that the HAL_UART_DMAStop() function should be used during the DMA transfer and not once the transfer is competed. It actually stops an ongoing DMA transfer.

As the issue is related to the generated code and not the driver, please allow me to close this thread as . Thank you for you comprehension.

With regards,