cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeMX 6.13.0 not generating calls to HAL_DMA_IRQHandler in GPDMA1_Channel0_IRQHandler

xlrl
Associate III

In our project we are using GPDMA for SAI transfers:

  • STM32CubeMX 6.13.0

  • STM32Cube_FW_U5_V1.7.0

  • STM32U535RE target

  • X-CUBE-FREERTOS 1.3.0 (FreeRTOS 10.6.2)

Description of the behaviour:

  • We this .ioc configuration STM32CubeMX does not create the calls to `HAL_DMA_IRQHandler`.
  • Note: in the past the time base call also was not generated (TIM6)
  • A different .ioc we were using for the NUCLEO board was producing the correct/expected code

Example of expected code:

void GPDMA1_Channel0_IRQHandler(void)
{
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 0 */

    /* USER CODE END GPDMA1_Channel0_IRQn 0 */
    HAL_DMA_IRQHandler(&handle_GPDMA1_Channel0);
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 1 */

    /* USER CODE END GPDMA1_Channel0_IRQn 1 */
}

Actually generated code (note the missing call):

void GPDMA1_Channel0_IRQHandler(void)
{
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 0 */

    /* USER CODE END GPDMA1_Channel0_IRQn 0 */
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 1 */

    /* USER CODE END GPDMA1_Channel0_IRQn 1 */
}

 Workaround:

void GPDMA1_Channel0_IRQHandler(void)
{
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 0 */
    HAL_DMA_IRQHandler(&handle_GPDMA1_Channel0);
    // comment out generated code, so a future generation
    // run does not create duplicate calls
#if 0
    /* USER CODE END GPDMA1_Channel0_IRQn 0 */
    /* USER CODE BEGIN GPDMA1_Channel0_IRQn 1 */
#endif
    /* USER CODE END GPDMA1_Channel0_IRQn 1 */
}
1 ACCEPTED SOLUTION

Accepted Solutions

Hello @xlrl 

Using your .ioc file, I've been able to generate the code expected:

void GPDMA1_Channel0_IRQHandler(void)
{
  /* USER CODE BEGIN GPDMA1_Channel0_IRQn 0 */

  /* USER CODE END GPDMA1_Channel0_IRQn 0 */
  HAL_DMA_IRQHandler(&handle_GPDMA1_Channel0);
  /* USER CODE BEGIN GPDMA1_Channel0_IRQn 1 */

  /* USER CODE END GPDMA1_Channel0_IRQn 1 */
}

I've just made a change on the .ioc file setting the "Call HAL handler" option for this interrupt:

STTwo32_0-1745218899359.png

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

6 REPLIES 6
STTwo-32
ST Employee

Hello @xlrl 

Do you have the same issue will using the STM32CubeMX V6.14.1?

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Yes, only a few comments changed.

Hello @xlrl 

Thank you so much for escalating this. I will have a look at this. Please add your .ioc file (based on the V6.14.1 of the STM32CubeMX).

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Here it is...

Hello @xlrl 

Using your .ioc file, I've been able to generate the code expected:

void GPDMA1_Channel0_IRQHandler(void)
{
  /* USER CODE BEGIN GPDMA1_Channel0_IRQn 0 */

  /* USER CODE END GPDMA1_Channel0_IRQn 0 */
  HAL_DMA_IRQHandler(&handle_GPDMA1_Channel0);
  /* USER CODE BEGIN GPDMA1_Channel0_IRQn 1 */

  /* USER CODE END GPDMA1_Channel0_IRQn 1 */
}

I've just made a change on the .ioc file setting the "Call HAL handler" option for this interrupt:

STTwo32_0-1745218899359.png

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thanks a lot for the answer.

What I still wonder why this happens in the first state?

The behaviour of the missing call is pretty and hard and time-consuming to debug.

 

Thanks a lot for your effect,

Alex