Skip to main content
PKrem.1
PKrem.1
Associate
January 18, 2022
Solved

Found a bug in the CubeMX Code Generation

  • January 18, 2022
  • 2 replies
  • 957 views

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.

This topic has been closed for replies.
Best answer by Khouloud OTHMAN

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.

2 replies

Javier1
Javier1
Principal
January 18, 2022

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

hit me up in https://www.linkedin.com/in/javiermuñoz/
Khouloud OTHMAN
Khouloud OTHMANBest answer
Associate
January 18, 2022

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.

Terms & ConditionsAccessibility statement