cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_Delay hangs after jumping from bootloader to FreeRTOS app (using TIM14 as tick source)

SaiKumar1
Visitor

Hello,

I am working on an STM32F446RE with a custom bootloader and FreeRTOS application.

  • Bootloader address: 0x08000000

  • Application address: 0x0800C000

  • The bootloader successfully jumps to the application by setting MSP, PC, and SCB->VTOR.

  • In my application, I configured FreeRTOS to use a hardware timer (TIM14) instead of SysTick as the OS tick source.

Problem:
When I flash the application directly, it runs fine.
But when I run through the bootloader, the application stops working as soon as it calls HAL_Delay(). If I comment out HAL_Delay(), the app continues normally. After the RTOS kernel starts, I get a HardFault on the first interrupt.

I suspect this is related to SysTick still being dirty from the bootloader, while my application is configured to use TIMx as the tick source.

My questions:

  1. What is the recommended way to cleanly reinitialize the HAL tick and interrupt system after jumping from a bootloader to an application that uses TIMx instead of SysTick?

  2. Should I override HAL_InitTick/HAL_GetTick in the application so that HAL_Delay() works with FreeRTOS (using TIMx ticks)?

  3. If HAL_Delay() must work before FreeRTOS scheduler starts, should I explicitly reconfigure SysTick in the application even though FreeRTOS uses TIM14?

  4. Is there a recommended sequence of peripheral deinitialization in the bootloader to avoid SysTick/interrupt leftovers?

Extra info:

  • Toolchain: GCC (CubeIDE, no optimizations)

  • Bootloader disables SysTick (SysTick->CTRL=0; SysTick->LOAD=0; SysTick->VAL=0;) before jump.

  • Application runs fine standalone, fails only after bootloader jump when HAL_Delay() is called.

Thanks in advance for guidance.

2 REPLIES 2
NicRoberts
Senior II

Isn't it recommended that you leave SysTick to FreeRTOS & designate a separate TIM for HAL use?

Yes, I am aware that FreeRTOS normally takes over SysTick, and the recommendation is to keep SysTick for FreeRTOS while designating a separate hardware timer for HAL timebase.In my case, I configured FreeRTOS to use a hardware TIM (not SysTick) for the RTOS tick source. That’s why HAL_Delay() is failing after bootloader jump — because Cube HAL by default still expects SysTick to be running for delays, unless HAL_InitTick is overridden.