DMA not working in CubeMX generated code - order of initialization

[waclawek.jan]

Here is a (possibly incomplete) list of threads affected by this CubeMX issue:

https://community.st.com/s/question/0D50X0000BVnBhASQV/bug-report-dma-and-adc-initialization-order-changed-in-stm32f4-hal-v1241-causing-incorrect-adc-operation

https://community.st.com/s/feed/0D50X0000BZFWRISQ5

https://community.st.com/s/question/0D50X0000BbKaA5SQK/haluarttransmitdma-doesnt

https://community.st.com/s/question/0D50X0000BbMcnpSQC/dma-adc-doesnt-work

https://community.st.com/s/question/0D50X0000BWqGdtSQF/haladcstartdma-init-msp-bug

https://community.st.com/s/question/0D50X0000BcS7tSSQS/stmcubeide-110-cubemx-540-switch-initialization-order

https://community.st.com/s/question/0D50X0000BVnBhASQV/bug-report-dma-and-adc-initialization-order-changed-in-stm32f4-hal-v1241-causing-incorrect-adc-operation

https://community.st.com/s/question/0D50X0000Bfs7MvSQI/stm32f3-adc-with-dma-bug

https://community.st.com/s/question/0D50X0000Bh6PntSQE/bug-mxdmainit-wrongly-placed-by-code-generator-haluarttransmitdma-does-not-work

https://community.st.com/s/question/0D50X0000BiA27LSQS/code-generated-calls-mxdmainit-too-late-after-mxspiinit

https://community.st.com/s/question/0D50X0000BcPXk2SQG/32f746-usart-dma-with-stemwin-not-working

 https://community.st.com/s/question/0D50X0000BmoZgKSQU/simple-uart1-dma-dosent-work-generated-with-latest-stm32cubemx-540-and-stm32f0-1110

This is just in case somebody would like to put up a sticky post with this...

JW

[EDIT] Further development with CubeMX5.5

https://community.st.com/s/question/0D50X0000Bwjgi7SQA/with-stm32cubemx-55-and-stm32h743-the-mxdmainit-function-is-not-called-at-the-right-time

[EDIT] Problem reappeared 6.3.0 https://community.st.com/s/question/0D53W000011uIPgSAM/adc-dmahandle-is-0

[EDIT] 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

[waclawek.jan]

Hi Amel,

this thread https://community.st.com/s/question/0D53W000004HgujSAC/the-stm32g484cetx-initialization-code-generated-by-stm32cubemx-has-a-bug appears to say that the problem persists in CubeMX v5.6.0 ?

JW

@Amel NASRI​ 

[JStor.2]

Can confirm that this is (still) a problem with recent STM32CubeIDE versions. I've run into this problem on STM32CubeIDE 1.7.0 (which has STM32CubeMX 6.3.0)

To reproduce:

• Start a new STM32 Project in STM32CubeIDE
• Enable an I2C peripheral in the Device Configuration Tool
• Generate code
• Add DMA channels to the I2C peripheral
• Generate code again
• Observe in `main.c` that `MX_I2C1_Init()` is called before `MX_DMA_Init()`
• Observe that the HAL_I2C_*_DMA() functions don't work

I tried both `HAL_I2C_Master_Transmit_DMA()` and `HAL_I2C_Master_Receive_DMA()`. Swapping the initialization order in the genrated code (calling `MX_DMA_Init()` before `MX_I2C1_Init()`) causes the functions to work.

Note that the following sequence leads to code that's generated in the correct order:

• Start a new STM32 Project
• Enable an I2C peripheral in the Device Configuration Tool
• Add DMA channels to the I2C peripheral
• Generate code

This implies that it's a bug in the "Updating Code" step.

I was able to fix the problem by manually moving `MX_DMA_Init()` before `MX_I2C1_Init()`. The code remained working even when the code was re-generated. It also meant that I didn't have to create a new .ioc file, or disable/re-enable peripherals, to fix the problem.

It also appears that similar problems exist with other DMA-enabled peripherals -- I repeated the same steps above with the I2C, SPI and USART peripherals, and observed the same behaviour for each of the peripherals.

For completeness, I was using STM32Cube FW_F0, targetting an STM32F042K6Tx (but I don't think this information is particularly relevant)

[JStor.2]

Can't edit, so just to note that manually changing the order in `main.c` actually didn't fix the issue. The correct fix is to re-order in the Device Configuration Tool -- as noted in https://community.st.com/s/question/0D50X0000Boy3eVSQQ/cubemx-540-generates-broken-code-for-stm32h7-stm32h7432-sai-dma

Use the buttons (3) to move `MX_DMA_Init()` above the peripheral init

[Amel NASRI]

Hi @JStor.2​ ,

Unfortunately this is a regression issue introduced wit STM32CubeMX 6.3 and STM32CubeIDE 1.7.0.

This is tracked internally and should be fixed on coming release of the tool. @Khouloud OTHMAN​ can confirm about fix availability.

Internal ticket 112040 : This is an internal tracking number and is not accessible or usable by customers.

-Amel

[FColl.1]

Funny how all my googling about "STM32 Can not set DMA configuration register" "DMA CR not writing with ADC" etc. etc. did not bring me here. I had to figure out the bug myself, wasting half a day. This is very annoying given it is a known issue. 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. Can someone from STM please make a note to add to the DMA documentation a tip to enable it first up??

[waclawek.jan]

> 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]

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]

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]

Hi @AndreaC​ ,

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

Please try to switch to this new release.

-Amel

[AndreaC]

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.

[waclawek.jan]

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]

Thank you. I changed Rank.

[Charles Miller]

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.

[Charles Miller]

Followup:

(CubeMX v6.5)

Why is my USB Virtual Com Port UART (UART3) initialization order entry grayed-out?

(For that matter, why is the DMA init grayed out, and prevented from being moved?)

This prevents a user fix by moving the DMA init to the top!