Reusing active timer for HAL Tick skips generation of its IRQHandler

[tpecar-ltek]

Describe the set-up

STM32CubeIDE

Version: 1.9.0
Build: 12015_20220302_0855 (UTC)

which uses

STM32CubeMX - STM32 Device Configuration Tool

Version: 6.5.0-RC4
Build: 20220225-1913 (UTC)

Copyright (c) 2022 STMicroelectronics. All rights reserved

Describe the bug

Moving the SYS timebase to a timer that was previously configured for something elese, but then disabled will cause an invalid configuration where the timer IRQs are not generated.

How To Reproduce

Issue is exclusive to the STM32CubeIDE Device Configuration Tool / STM32CubeMX code generation.

It is reproducible with an empty project.

• start with a fresh project on F1 platform, for example STM32F103RG MCU

  

  

• generate code using defaults

• configure free timer (eg. TIM6, will be used for the rest of this example) for HAL timebase, generate code

  

• revert HAL back to systick, generate code

  

• manually configure the timer (TIM6), enable interrupts, generate code

  

  

  As it was previously used for HAL, the timer gets configured with an interrupt priority of 15 (this is also a bug)

  

• disable the timer (TIM6), reuse it for HAL timebase source again, generate code

  

  

  This will generate the stm32f1x_hal_timebase_tim.c, configured for the timer (TIM6), but its IRQ Handlers will get removed, causing the platform to hang in Default_Handler at start.

  Notably, the following configuration line will be missing

NVIC.TIM6_IRQn=true\:15\:0\:false\:false\:true\:false\:true\:true

One can recover from this configuration by

• reverting HAL to SysTick
• closing the Device Configuration Tool and reopening it back again
• configuring HAL to that timer

Closing and reopening also seems to mitigate the interrupt priority assignment when manually configuring the timer, it will be configured as other devices (in a fresh project it should be 5).

I could not reproduce it with the above procedure, but such changes may also cause the change of TICK_INT_PRIORITY

Additional context

There are some other related bugs

• https://community.st.com/t5/stm32cubeide-mcus/value-of-tick-int-priority-default-value-changed/td-p/136027
• https://community.st.com/t5/stm32cubeide-mcus/tick-int-priority-affected-by-enabling-trace-outputs/m-p/588892/highlight/true#M20524

[tpecar-ltek]

Previously mentioned

I could not reproduce it with the above procedure, but such changes may also cause the change of TICK_INT_PRIORITY

There seems to be a code path / UI element in Device Configuration Tool that I do not know of, but if one manually changes the interrupt priority of the timer that is currently used as the HAL timebase, this will also update the TICK_INT_PRIORITY

diff --git a/sw/app/Core/Inc/stm32f1xx_hal_conf.h b/sw/app/Core/Inc/stm32f1xx_hal_conf.h
index 2fc99ba..0c4f67e 100644
--- a/sw/app/Core/Inc/stm32f1xx_hal_conf.h
+++ b/sw/app/Core/Inc/stm32f1xx_hal_conf.h
@@ -129,7 +129,7 @@
   * @brief This is the HAL system configuration section
   */
 #define  VDD_VALUE                    3300U /*!< Value of VDD in mv */
-#define  TICK_INT_PRIORITY            0U    /*!< tick interrupt priority (lowest by default)  */
+#define  TICK_INT_PRIORITY            15U    /*!< tick interrupt priority (lowest by default)  */
 #define  USE_RTOS                     0U
 #define  PREFETCH_ENABLE              1U

diff --git a/sw/app/app.ioc b/sw/app/app.ioc
index 1cb52d3..06ddb91 100644
--- a/sw/app/app.ioc
+++ b/sw/app/app.ioc
@@ -196,7 +196,7 @@ NVIC.SavedPendsvIrqHandlerGenerated=true
 NVIC.SavedSvcallIrqHandlerGenerated=true
 NVIC.SavedSystickIrqHandlerGenerated=true
 NVIC.SysTick_IRQn=true\:15\:0\:false\:false\:false\:true\:false\:true\:true
-NVIC.TIM6_IRQn=true\:0\:0\:false\:false\:true\:false\:false\:true\:true
+NVIC.TIM6_IRQn=true\:15\:0\:false\:false\:true\:false\:false\:true\:true
 NVIC.TimeBase=TIM6_IRQn
 NVIC.TimeBaseIP=TIM6
 NVIC.USART1_IRQn=true\:5\:0\:true\:false\:false\:true\:true\:true\:true

[TOUNSTM]

Hello @tpecar-ltek ,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards,

[ALABSTM]

Hi @tpecar-ltek,

I hope you are doing well. First of all, please excuse this delayed reply. Thank you for this detailed report and the many screenshots attached.

I have tried to reproduce the above steps using STM32CubeMX 6.10.0 and encountered no issue. I have tried twice, once starting with a STM32F1 as MCU and once with a STM32F4. The generated file stm32f1xx_hal_timebase_tim.c was the same the first time I had generated the code, and the third time, after I had disabled the timer and set it back as a time base for the system.

In your original description, you mentioned using 6.5.0-RC4. I guess the issue has been solved in the meanwhile.

Please allow me to close this issue. Thank you for your comprehension and thank you again for the detailed report.

With regards,