STM32F446: bug when using DMA UART

[THerp.1]

We wanted to use a UART periphal in transfer DMA mode. When configuring it with CubeMX, nothing happens, event when trying it on an empty project.

When manually configuring the various registers for DMA transfer between memory and the peripheral data register, the behaviour was correct, so I suspected an issue with the HAL library.

I tracked the bug down to the function HAL_DMA_Init in Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c

The following line (line 251) is supposed to set the config register for the appropriate DMA stream:

hdma->Instance->CR = tmp;

But, when step debugging, it appears to have no effect on the register (as seen on the SFRs tab), even if the tmp variable has the correct value... How could this be explained? A weird silicon bug that doesn't allow to set the register in certain state of the mcu? An error in the library?

In the meantime, we can just set the DMA stream CR register from the main function.

Maybe it's worth mentioning that the issue occured with two different MCUs.

[TDK]

Could be explained by the DMA clock not being initialized. Doesn't really make sense otherwise. The processor doesn't care where the code changing the CR register is located. Nor does it know.

[waclawek.jan]

> Could be explained by the DMA clock not being initialized.

https://community.st.com/s/question/0D50X0000Bmob3uSQA/dma-not-working-in-cubemx-generated-code-order-of-initialization ?

JW

[THerp.1]

Indeed! Adding these lines (copied from MX_DMA_Init() ) before the USART init function solves the issue without having to manually edit the DMA register!

/* USER CODE BEGIN SysInit */
__HAL_RCC_DMA2_CLK_ENABLE(); // DMA2 for USART1
/* USER CODE END SysInit */

Thank you! Should have asked before, it would have saved me a painful debugging...

[THerp.1 · Accepted solution]

Actually, I updated STM32CubeIDE (and cubeMX) to the latest version, and the issue is no longer present, so no workaround needed.