search

STMicroelectronics / STM32CubeF7

STM32Cube MCU Full Package for the STM32F7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
331 stars 193 forks source link

MX_DMA_Init() should be called BEFORE other periphery Init #76

Closed adam-szabo-xtalin closed 1 year ago

adam-szabo-xtalin commented 1 year ago

Describe the set-up

Describe the bug MX_DMA_Init() is called after MX_USART2_UART_Init(), therefore initializing USART2 with DMA feature goes to fault state.

How To Reproduce

  1. Indicate the global behavior of your application project. Use DMA to transmit UART frames.
  2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...). Wrong code generation order for MX_xxx_Init() functions.
  3. The use case that generates the problem. UART with DMA
  4. How we can reproduce the problem. Setup the USART2 periphery without DMA and generate code. Later decide to use DMA for transmission, so add DMA to USART2, and generate code.

The generated code will be:

MX_GPIO_Init();
MX_USART2_UART_Init();
MX_DMA_Init();

Transmission with DMA will not work, as during HAL_UART_MspInit() the hdma_usart2_tx cannot be initialized.

With the following order everything works fine:

MX_GPIO_Init();
MX_DMA_Init();
MX_USART2_UART_Init();
ASELSTM commented 1 year ago

Hi @adam-szabo-xtalin,

The issue you have reported has been already fixed in the previous version of CubeMX. Would you please try to use the latest version of the CubeMX tool v6.6.1.

Actually, we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community . Now, as the issue is fixed and as it is not directly related to the software component published within this repository (CMSIS, HAL, BSP, etc.) but rather to our ecosystem (namely the Cube MX tool), please allow me to close it.

With regards,