Skip to main content
Visitor II
May 3, 2024
Solved

[BUG] Wrong timer interrupt handling in HAL for STM32L496

  • May 3, 2024
  • 2 replies
  • 1198 views

Hello,

the following code is generated by CubeMX 6.11.1 in module stm32l4xx_it.c:

/**
 * @brief This function handles TIM1 trigger and commutation interrupts and TIM17 global interrupt.
 */
void TIM1_TRG_COM_TIM17_IRQHandler(void)
{
 /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 0 */

 /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 0 */
 HAL_TIM_IRQHandler(&htim1);
 HAL_TIM_IRQHandler(&htim17);
 /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 1 */

 /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 1 */
}

/**
 * @brief This function handles TIM1 capture compare interrupt.
 */
void TIM1_CC_IRQHandler(void)
{
 /* USER CODE BEGIN TIM1_CC_IRQn 0 */

 /* USER CODE END TIM1_CC_IRQn 0 */
 HAL_TIM_IRQHandler(&htim1);
 /* USER CODE BEGIN TIM1_CC_IRQn 1 */

 /* USER CODE END TIM1_CC_IRQn 1 */
}

Interrupts for TIM1 (capture) and TIM17 (global) are both activated, but with different priorities.

The problem is that TIM1_TRG_COM_TIM17_IRQHandler() handles also the capture interrupts from TIM1 with same function HAL_TIM_IRQHandler(&htim1) (called from 2 different interrupt sources).

Therefore the TIM1 capture functions can be called with wrong priority or twice (race condition causes additional interrupt without reason).

 

I think the common HAL timer interrupt handler has to be split in different parts (one for capture processing, one for trigger processing, etc.) and each part should called only once from the right interrupt source (the int handler would also be shorter and faster).

Same problem could also occure on other interrupt handlers with multiple sources or other processor families...

 

    This topic has been closed for replies.
    Best answer by Sarra.S

    Hello again @SStor

    This issue is corrected with STM32CubeMX-6.15.0 published on st.com 

    2 replies

    ST Employee
    May 3, 2024

    Hello @SStor,

    I appreciate your input, I confirmed this issue, and I created an internal ticket for the responsible team (Ticket 180631), I will keep you updated!  

     

    Sarra.SAnswer
    ST Employee
    July 31, 2025

    Hello again @SStor

    This issue is corrected with STM32CubeMX-6.15.0 published on st.com