cancel
Showing results for 
Search instead for 
Did you mean: 

Found a bug in the CubeMX Code Generation

PKrem.1
Associate II

There is a bug in the CubeMX Code Generation in STM32CubeIDE Code Generation (Version 1.7.0 updated to 1.8.0) for the STM32F767ZI. (STM32Cube FW_F7 V1.16.2)

The bug was found by debugging a not working auto generated code that is using a DMA circular buffer to read from uart.

In the auto generated initialization code for the hardware the ordering of the function calls was:

MX_GPIO_Init();
MX_USART3_UART_Init();
MX_DMA_Init();

Because DMA_Init starts the clock to the dma the dma isn't clocked when initializing the uart which uses the DMA.

This leads to a non functioning dma transfer and the uart overflow error is triggered because nothing is reading from the uart peripheral.

As a work arround you can write:

LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_DMA1);

before the block with the MX initializiation functions or you can swap the calls to dma init and uart init.

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @PKrem.1​ ,

First let me thank you for having reported.

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, and it seems to be corrected for some use cases.

For example, starting a project from scratch and configuring I2S and DMA in one shot (without switching to Project Manager view before configuring I2S DMA request), MX_DMA_Init Function call will be in its correct position.

With this being said, and as mentioned by @Javier Muñoz​ , you can refer to the this post proposing a workaround to overcome this issue: re-order initialization functions through Project Manager view > Advanced Settings tab.

Hope this clarifies the situation.

Khouloud.

View solution in original post

2 REPLIES 2
Javier1
Principal

This is a known issue, cubeMX generates the init function in the wrong order.

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

we dont need to firmware by ourselves, lets talk

Hello @PKrem.1​ ,

First let me thank you for having reported.

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, and it seems to be corrected for some use cases.

For example, starting a project from scratch and configuring I2S and DMA in one shot (without switching to Project Manager view before configuring I2S DMA request), MX_DMA_Init Function call will be in its correct position.

With this being said, and as mentioned by @Javier Muñoz​ , you can refer to the this post proposing a workaround to overcome this issue: re-order initialization functions through Project Manager view > Advanced Settings tab.

Hope this clarifies the situation.

Khouloud.