DMA not working in CubeMX generated code - order of initialization

> Part of the problem is that nowhere in any of the examples or documentation for DMA does it mention the fact the one must enable the clock to the DMA before doing anything.

True, and the RM may've explicitly mentioned that; OTOH, this is one of the things which are expected to come from general understanding of the modern electronics, a.k.a. "everybody knows" that *all* peripherals (bar some rare exceptions) need to have clock enabled before they are used.

Also, this particular issue stems from the desire of users to generate code entirely by clicking and it's probably a well-deserved lesson to highlight the pitfalls of that process.

JW

Standa Standa · ‎2021-11-21

Thanks for the post... Confirming this bug with this configuration in CubeMX 6.3.0:

ADC group conversion regular, triggered by TIM1. Data via DMA into circular buffer. Memory address wont increment and transaction ends up with ADC overrun.

Changing the order of init routines for DMA and ADC as described above fixes the issue (dma initialized first).

MX_DMA_Init();

MX_ADC1_Init();

AndreaC · ‎2021-12-06

Also with STM32L0, Cube 6.3.0 and libraries V1.12.1, if

  MX_USART1_UART_Init();

precedes

  MX_DMA_Init();

then bit MINC in DMA CCR register is not set and DMA reception doesn't work

Amel NASRI · ‎2021-12-06

Hi @AndreaC ,

This known issue should be already fixed with STM32CUbeMX 6.4.0 version.

Please try to switch to this new release.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AndreaC · ‎2021-12-06

Hi Amel and thanks for your reply.

I updated CubeMX and regenereated the code but the issue is still present.

I applied @JStor.2 suggestion to make the solution permanent.

Amel NASRI · ‎2021-12-06

Indeed, that is an expected behaviour because you are not generating your project from scratch but based on an ioc file with issue.

This is said, an internal ticket is submitted in order to improve the tool and avoid such side effect.

Internal ticket number: 118838 (PS: This is an internal tracking number and is not accessible or usable by customers).

Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AndreaC · ‎2021-12-06

Got it, thanks.

waclawek.jan · ‎2021-12-07

Here is the official method to fix the incorrect order, if project was generated in "incorrect" version of CubeMX:

https://community.st.com/s/question/0D53W00001EzCmCSAV/mxdmainit-order-in-the-mainc-file-generated-by-stm32cubemx-how-to-fix

JW

DPaen.2 · ‎2021-12-24

Thank you. I changed Rank.

Charles Miller · ‎2022-03-25

Unfortunately, the bug persists in version 6.5 (I'm working with STM32F756, Nucleo board)

The work-around is to call

__HAL_RCC_DMA1_CLK_ENABLE()

and/or

__HAL_RCC_DMA2_CLK_ENABLE()

before calling any of the ...Init functions.

Peripherals using DMA assume DMA configuration functions (register manipulations) are working (if called)--and this only happens if the DMA clocks are first enabled. Sent a message Imen Dahmen.