cancel
Showing results for 
Search instead for 
Did you mean: 

Systick is not ticking in Custom Bootloader for STM32H743 after jumping to the main application and then coming back to the Bootloader

smati2
Associate II

I have written a Custom Bootloader for STM32H743. It resides at 0x08000000 (Sector 0) and occupies for a maximum of 1 sector (128KB). The main application resides at 0x08040000 (Sector 1 thru sector 7). Upon reset, Custom Bootloader starts and checks to see if user wants to do a firmware update. If not, it jumps to the main application. Within the main application, if user decides to do a firmware update, then the main application jumps to the custom bootloader. All that works fine. However, upon return to the bootloader Systick does not tick (HAL_Delay) does not operate! Why?

Note that all the standard initialization do take place including the HAL_Init() and  SystemClock_Config(). I am using SPI4 and USART2 in the custom bootloader and all get initialized properly and everything works except for Systick! Please assist.

Thanks.

4 REPLIES 4
MM..1
Chief II

Dobug your code and will see. But better way to repeat start is reset , some repeated HAL inits without deinits produces unpredict results. I use for start boot IWDG or WWDG

gbm
Lead III

HAL initializes the SysTick multiple times during startup. If both bootloader and app are HAL-based, these multiple inits are in effect.

In my bootloaders I switch between the loader and the app via reset based on magic value in a backup register. The condition for entering boot or app is checked at the very beginning of the code. This way nothing is initialized when the code starts.

Make sure interrupts are not disabled.

That you don't call from an IRQHandler or callback routine.

The vector table address is correctly set.

The SysTick is running.​

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

Thank you for your feedback. From another ST community link, I got the HAL_Delay to work. I actually had to set SCB->VTOR and enable interrupt prior to the jump as seen below:

SCB->VTOR = BootAddr + 4;

  __enable_irq(); /* Re-enable all interrupts */

Apparently in some flavors of STM32 (in my case STM32H743), the low address byte is important. Hence, SCB->VTOR had to be "BootAddr + 4" as opposed to BootAddr.

NOW......, I have another issue where upon start with Bootloader starting (under debug), the interrupt handler for my SPI (SPI4_IRQHandler) gets hit. From there, it calls HAL_SPI_IRQHandler(&hspi4); but, the callback routine (HAL_SPI_TxRxCpltCallback) does not get reached! Yet, it seems like if the routine is sent back to the main app and then upon firmware update and jumping back to the Bootloader from main application, then HAL_SPI_TxRxCpltCallback appears the get hit.

I really need HAL_SPI_TxRxCpltCallback to be hit no matter what to have the SPI on an interrupt routine process. Any help/suggestions would be appreciated.

Thank you.