Showing results for 
Search instead for 
Did you mean: 

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

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:



here is my files.

tried with STM32F03

tried on another board bluepill STM32F103C8T6

Have you checked my project file?

Any update about the problem and solution?​

Hello parth kothiya,

I apologize for the late reply,

I checked your project and I see that you are still using v6.4.0. The issue is fixed on 6.5.0 when the project is created from scratch. However, there are some cases where the order is not generated correctly.

I would advise you to migrate your project from v6.4.0 to v6.5.0, unfortunately this is one of the cases where the issue still exists.

The dev team is aware of this and they are working on it. It will be properly fixed as soon as possible. I will keep you posted with updates.

In the meantime, please make sure to apply the workaround mentioned in this thread.

Sorry for the inconveniences,




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

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.


Marcelo Jimenez
Associate III

That is really annoying. I am using STM32CubeIDE Version 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.




Hello @Sara BEN HADJ YAHYA​ I have just been fighting this issue for a few days and finally solved on my own before finding this thread. The strange thing is I built a different project with the same version CubeMX (6.4) and one project listed MX_DMA_Init() in the correct location (in my case, before ADC init). But another project listed DMA init AFTER ADC init. I followed your guidance to modify the .ioc file (delete ProjectManager.functionlistsort=....) and it worked. I have since installed 6.5 and the issue persists. Will ST please address this?

hello @CWalk.1​ ,

Thanks for your feedback,

We are aware of this issue and the dev team is working on it. I will let you know once the issue is solved.



I also have seen this with I2C Init