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:

[Sara BEN HADJ YAHYA]

Hello @Florian Rösel​ ,

Issue confirmed from my side, it seems that the DMA init order is not set correctly in H7 devices.

I submitted an internal ticket, I will keep you posted.

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

If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)

Sara.

[Piranha]

We have a 3 year anniversary!

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

[WLear]

This problem STILL exists in CubeMX V6.6.1.

The original workaround of hand editing the .ioc file does correct the issue

[Georgy Moshkin]

Wrong initialization order on STM32H7B0VBT6 latest STM32CubeIDE and firmware.

Can't change initialization order in advanced settings, arrow buttons are grayed out:

 IOC file attached

1. new project
2. configured HSE, voltage range 0
3. added USART1, changed to alternate pins
4. configured USART1 DMA for TX, RX
5. enabled USART1 global interrupt
6. "generate code" button

 current solution is to manually edit ProjectManager.functionlistsort line of IOC file;

before:

ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_USART1_UART_Init-USART1-false-HAL-true,4-MX_DMA_Init-DMA-false-HAL-true,0-MX_CORTEX_M7_Init-CORTEX_M7-false-HAL-true

after:

ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_DMA_Init-DMA-false-HAL-true,4-MX_USART1_UART_Init-USART1-false-HAL-true,0-MX_CORTEX_M7_Init-CORTEX_M7-false-HAL-true

[victagayun]

Is the CubeMX open source or will be open sourced, so everyone can check the problem/s?

[MBook.1]

Using STM32CubeMX 6.6.1 RC2 Build 20220706-1420 (UTC) and STMCubeIDE 1.10.1

Started a new project for STM32H730 with just a single ADC enabled. This worked under polling. Then tried to enable several ADC channels on ADC1 with DMA.

DMA still gets fixed under all the other function calls and can't be moved - why? At least let the user change the order if it's not going to work automatically.

The ioc file doesn't match the instructions given in previous posts so I'm stuck with changing the order of calls in the program every time I change an option. It's definitely not cool.

Please get this changed properly.

[victagayun]

Seems to be a problem when you later decide that you may need a DMA at a later time.

[victagayun]

The only way to solve this is to open-source it!

[MBook.1]

@victagayun​ Thanks for the reply

@Support I've tried it with a Nucleo board (Nucleo STM32L4R5ZI) I have here. I can run the ADC to DMA with no problems. It is definitely something to do with the STM32H730 initialisation file - other devices (at least the one I've used) behave in the way expected. The problem is we're using the H730 and the DMA doesn't work at all because it's in the wrong place - and it can't be moved using the Project Manager.

My colleague is trying to test the OctoSPI using MDMA and it has the same problem.

Please fix this so we can get on and test the board and design our software.

[MRich.2]

Test with STM32CubeIDE v1.10.1 containing STM32CubeMX STMicroelectronics 6.6.1.202207061420, creating project for NUCLEO-H7232ZG to use DMA to move data from memory to USART3.

Initialization order created by program does not work because code called by MX_USART3_UART_Init attempts to change DMA1 peripheral registers before DMA1 has been enabled in RCC.

Initialization order created by STM32CubeMX:

/* Configure the system clock */

 SystemClock_Config();

 /* USER CODE BEGIN SysInit */

 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */

 MX_GPIO_Init();

 MX_ETH_Init();

 MX_USART3_UART_Init();

 MX_DMA_Init();

 MX_USB_OTG_HS_USB_Init();

 /* USER CODE BEGIN 2 */

In Project Manager - Advanced Settings - Generated Function Calls, the engry for MX_DMA_Init() is greyed out and cannot be moved, butthe MX_USART3_UART_Init() entry can be shifted down to correct the error.