MX_DMA_Init order in the main.c file generated by STM32CubeMX, How to fix?

[Khouloud OTHMAN]

When DMA is used, the MX_DMA_Init shall always be called before any other HAL_***_Init (where *** is any peripheral with a HW dependency on DMA init code).

A regression was detected in the previous STM32CubeMX version 6.3.0 (STM32CubeIDE Version: 1.7.0 ) generating a wrong order of initialization functions.

This issue was fixed in the latest STM32CubeMX version 6.4.0. Thus, newly created project with this version will generate the correct initialization functions order.

Because the calling order is saved into the ioc file, the misplacement call to MX_DMA_Init() remains the same when trying to migrate automatically an old project from a buggy old version to the fixed version. The order stays the same and the generated code will be unfunctional.

For any old ioc file created by any STM32CubeMX version up to 6.3.0 included, hereafter some steps to overcome this misbehavior:

• Open the saved .ioc file (already created with 6.3.0 version) with any text editor installed in your machine and delete the line: ProjectManager.functionlistsort=....

 

• After saving the modification, re-open the .ioc file with latest CubeMX version 6.4.0 ( STM32CubeIDE Version: 1.8.0).
• Through Project Manager view > Advanced Settings tab, make sure that the initialization functions are correctly ordered and re-generate your project:

[ABlig.1]

Many thanks for posting this. It saved my sanity after a couple of frustrating days trying to get DMA working for the LPUART and the ADCs.

There are many posts on stackoverflow etc. saying that the DMA must be initialised before the thing that uses it, e.g. ADCs. I had moved the DMA initialisation to position 3 in the start up order (after GPIO and SystemClock_Config) but DMA didn't work. When I moved it to position 2 as shown above, DMA worked. So there must be some interaction between the DMA and the SystemClock_Config initialisation that is preventing the DMA from running correctly.

tldr: Make sure the order is:

1. GPIO
2. DMA
3. SystemClock_Config
4. the rest.

[SSchu.4]

I have just generated code with this IDE

STM32CubeIDE

Version: 1.8.0

Build: 11526_20211125_0815 (UTC)

OS: Linux, v.5.13.0-28-generic, x86_64 / gtk 3.24.20, WebKit 2.34.4

Java version: 11.0.11

CubeMX Version: 6.4.0-RC4

Build: 20211122-2105 (UTC)

Still: Wrong code. WTF ST?

 /* Configure the system clock */
 SystemClock_Config();
 
 /* USER CODE BEGIN SysInit */
 
 /* USER CODE END SysInit */
 
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_ADC1_Init();
 MX_DMA_Init();

[parth kothiya]

I deside to switch another MCU.

Lots of bugs and when you design your own product using ST s MCU then you can't get solution immediately.​

[PAkRad]

Version 6.5.0 - same thing!!!

[Zuffouille]

Exact, same issue for CubeMX, V6.5.0

[waclawek.jan]

@PAkRad​ ,

is this a project newly started in version 6.5.0, or did you migrate a project created in older version of CubeMX?

JW

[PAkRad]

New project from scratch.

[PAkRad]

@Community member​ new project from scratch, actually to test the new version.

[parth kothiya]

In latest version of cubeMX also same issue not resolved.

​

MX_GPIO_Init();

MX_ADC1_Init();

MX_DMA_Init();

​

Dma not working.​

[Adeni]

When you say not working, did you get zeros in the output? Or did you get in a deadlock​?

[Sara BEN HADJ YAHYA]

Hello @parth kothiya​ , @PAkRad​ ,

I re-did the test from my part on an STM32H7 and I couldn't see the issue, the order is generated correctly.

Could you please share your ioc file and provide us with the exact scenario that led to this issue?

Thanks,

Sara.

[parth kothiya]

here is my files.

tried with STM32F03

[CloverGit]

@Sara BEN HADJ YAHYA​ 

There is a way to reproduce the error.

first configure ADC without DMA first, press Ctrl + S to save the .ioc file, and then configure the DMA parameters of ADC, and your initialization function order will be wrong.

If you are configuring ADC and DMA at the same time, and then save the .ioc file, you will not have this problem.

I tested on STM32F103ZET6

[Sara BEN HADJ YAHYA]

Hello @CloverGit​ ,

Yes you are right, this is one of the cases where the issue exists. As I mentioned in my previous comment, the best way to avoid the wrong init order generation is to always check the  Project Manager view > Advanced Settings tab and make sure that the order is right.

I will let you know once the fix is properly done.

Sara.

[Marcelo Jimenez]

That is really annoying. I am using STM32CubeIDE Version 2.0.100.202110131350. STMCubeMX is Version 6.5.0-RC4 Build: 20220225-1913 (UTC)

I am unable to step up the DMA initialization order in the "Project Manager -> Advanced Settings" tab. I get a gray line over MX_DMA_Init.

The workaround was to click in "Do Not Generate Function Call" for MX_DMA_Init and call it by hand in /* USER CODE BEGIN SysInit */ just before all peripherals are initialized.

Regards,

Marcelo.