cancel
Showing results for 
Search instead for 
Did you mean: 

Hal_Delay doesn't work after Jump to application

kadirdagkoyluoglu
Associate

Hi,

I have been working on STM32F4 discovery board, I have developed Bootloader Code. There is 2 option to jump to application that includes blinking led app. First button interrupt runs perfectly, i mean hal_delay() runing with no issue.
Second option is, if UART interrupt gets the jump command and address from my computer. In this situation it jumps to application and leds are turn on but not blinking because of hal_delay() func (i guess). In 2 option before the jump func if i use hal_delay() , it crahs also.

1 ACCEPTED SOLUTION

Accepted Solutions
PeleAB
Associate

You’re performing complex operations directly within the UART interrupt handler.

When `processBootloaderCommand()` is called from `HAL_UART_RxCpltCallback()`, you’re executing it in interrupt context. If this function uses `HAL_Delay()` or jumps to the application, it causes problems because HAL_Delay() relies on SysTick interrupts which can’t execute properly when you’re already in an interrupt handler. Additionally, jumping to the application from within an interrupt leaves the system in an inconsistent state.

The solution is to use a flag-based approach: set a flag in the interrupt handler when a command is received, then check and process that flag in your main loop. This way, `processBootloaderCommand()` and any subsequent application jumps happen in the main program flow rather than interrupt context, allowing HAL_Delay() to work properly.

You should also disable all interrupts before jumping to the application to ensure a clean transition, and add buffer overflow protection to prevent the rxBuffer from overrunning if too much data is received.

This explains why the button method works (it’s processed in main loop) but the UART method fails (it’s processed in interrupt context).​​​​​​​​​​​​​​​​

View solution in original post

3 REPLIES 3
PeleAB
Associate

You’re performing complex operations directly within the UART interrupt handler.

When `processBootloaderCommand()` is called from `HAL_UART_RxCpltCallback()`, you’re executing it in interrupt context. If this function uses `HAL_Delay()` or jumps to the application, it causes problems because HAL_Delay() relies on SysTick interrupts which can’t execute properly when you’re already in an interrupt handler. Additionally, jumping to the application from within an interrupt leaves the system in an inconsistent state.

The solution is to use a flag-based approach: set a flag in the interrupt handler when a command is received, then check and process that flag in your main loop. This way, `processBootloaderCommand()` and any subsequent application jumps happen in the main program flow rather than interrupt context, allowing HAL_Delay() to work properly.

You should also disable all interrupts before jumping to the application to ensure a clean transition, and add buffer overflow protection to prevent the rxBuffer from overrunning if too much data is received.

This explains why the button method works (it’s processed in main loop) but the UART method fails (it’s processed in interrupt context).​​​​​​​​​​​​​​​​

Actually i have tried that method before but i did it one more time and didn't work. I want share with you what i did maybe you will be able to see the mistakes.

If you disable interrupts you must re-enable them.

SCB->VTOR needs to point to your new vector table, that's pointing at the SysTick_Handler()

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..