2025-06-17 9:23 AM
Hi everyone,
I'm working on an STM32H7RS project (NUCLEO-H7S3L8) with the following setup:
Bootloader in internal flash (0x08000000)
Application in external OSPI flash (XIP) at 0x70000000
Using Azure RTOS (ThreadX)
Using TIM6 as the HAL time base (not SysTick)
Configured using latest STM32CubeMX and STM32CubeIDE (v1.18.1)
What I already checked:
The vector table is correctly set in main() of the application:
int main(void)
{
/* USER CODE BEGIN 1 */
#define APPLICATION_VECTOR_TABLE ((uint32_t)0x70000000)
SCB->VTOR = APPLICATION_VECTOR_TABLE;
__DSB();
__ISB();
/* USER CODE END 1 */
/* Enable the CPU Cache */
/* Enable I-Cache---------------------------------------------------------*/
SCB_EnableICache();
/* Enable D-Cache---------------------------------------------------------*/
/* MCU Configuration--------------------------------------------------------*/
/* Update SystemCoreClock variable according to RCC registers values. */
SystemCoreClockUpdate();
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* USER CODE BEGIN Init */
/* USER CODE END Init */
/* USER CODE BEGIN SysInit */
/* USER CODE END SysInit */
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_HPDMA1_Init();
MX_GPDMA1_Init();
uint32_t tickTest3 = HAL_GetTick();
MX_ADC1_Init();
MX_ADC2_Init();
MX_I2C2_Init();
MX_SBS_Init();
MX_UART4_Init();
MX_UART5_Init();
MX_TIM3_Init();
MX_TIM2_Init();
MX_UART7_Init();
MX_UART8_Init();
MX_I2C3_Init();
MX_SPI1_Init();
MX_SPI2_Init();
MX_ETH_Init();
MX_FLASH_Init();
MX_DTS_Init();
MX_TIM1_Init();
/* USER CODE BEGIN 2 */
/* Initialize leds */
BSP_LED_Init(LED_GREEN);
BSP_LED_Init(LED_BLUE);
BSP_LED_Init(LED_RED);
/* USER CODE BEGIN BSP */
/* -- Sample board code to send message over COM1 port ---- */
printf("Welcome to STM32 world !\n\rApplication project is running...\n\r");
/* -- Sample board code to switch on leds ---- */
BSP_LED_On(LED_GREEN);
BSP_LED_On(LED_BLUE);
BSP_LED_On(LED_RED);
/* USER CODE END BSP */
/* USER CODE END 2 */
MX_ThreadX_Init();
HAL_Init() is called before anything else
HAL_InitTick() has been overridden to use TIM6
HAL_TIM_Base_Start_IT() returns HAL_OK
TIM6_DAC_IRQHandler() is defined and includes a call to HAL_IncTick() via HAL_TIM_IRQHandler()
if (htim->Instance == TIM6) {
HAL_IncTick();
}
The TIM6 interrupt priority is set to 14, and NVIC config is applied
uwTick remains at 0 the entire time — HAL_GetTick() and HAL_Delay() don’t function
MX_Eth_Init works, indicating that clocks, NVIC, and system init are not completely broken
Using the default ThreadX integration generated by STM32CubeMX for Azure RTOS
I also upleaded my IOC file. Are there any known issues or things i have overseen?
Solved! Go to Solution.
2025-06-19 8:25 AM
SOLVED:
Upon further inspecting the SFR, i saw that the hardware timers were increasing. By setting setting enable_irq() at the top of main(), it worked.
For people who will find this later, this is how uwTick works:
The uwTick variable is only incremented when this chain of events happens:
The chain was breaking at Step 2. The TIM6_IRQ_Handler was never being executed, even though the hardware timer is overflowing. enable_irq() enables the interrupts.
2025-06-17 10:03 AM
14 is a lower priority than 0. You typically want SysTick (or whatever you're using for it) to be a higher priority (numerically lower) than others. It's probably an issue with this.
2025-06-17 10:06 AM - edited 2025-06-17 10:44 AM
This is my application NVIC:
I set everything to 1 except the not editeble interrupt handlers as wel as TIM6. Upon running, HAL_GetTick still return 0 all the time, as uwTick is not increasing.
2025-06-17 11:44 AM
That screenshot shows systick is lower priority than everything else.
Put TIM6 at 0 and everything else at 15.
If that doesn't work, show the stack trace when HAL_Delay fails.
2025-06-18 4:53 AM
2025-06-18 5:55 AM
> void TIM6_IRQHandler(void)
The relevant IRQ handler is TIM6_DAC_IRQHandler, but the stm32h7*_it.c file has TIM6_IRQHandler defined.
In your original post, you said TIM6_DAC_IRQHandler was defined. Did something change there?
If this is a CubeMX bug, please include the IOC if you can.
If that's not it, here's what I would do:
2025-06-18 6:49 AM
Very interesting that you pointed that out.
I had to regenerate the code due to the change of the change of the NVIC priorities. Interesting thoug, not only is there no TIM6_DAC_IRQHandler to be found anymore.
Sadly i didnt have version control enabled...
I also appended the IOC file.
Also i recorded a video how the SFR values for TIM6 change, but upon inspection the variables, they change from beeing uninitialized to receiving 0 as value, as if uwTick isnt getting TIM6 as reference.
2025-06-19 8:25 AM
SOLVED:
Upon further inspecting the SFR, i saw that the hardware timers were increasing. By setting setting enable_irq() at the top of main(), it worked.
For people who will find this later, this is how uwTick works:
The uwTick variable is only incremented when this chain of events happens:
The chain was breaking at Step 2. The TIM6_IRQ_Handler was never being executed, even though the hardware timer is overflowing. enable_irq() enables the interrupts.