Question
Why need manually __enable_irq() after Bootloader jump to application
Hi,
I have a bootloader used 3 years ago on 2020 on STM32F437 and it works perfectly.
This year, I am trying to use the same bootloader on STM32F205 but got problem that after the jump, the Application is not running.
After a long time debugging I found the Application is stuck in HAL_Delay()and osDelay().
So, I manually added the __enable_irq() in the beginning of the Application code and it magically works.
I know I have __disable_irq(); in the Bootloader code but the problems really confused me are:
- Why I need to manually add the __enable_irq() in the Application code? My Application code can work alone, So, should all the necessary interrupts be initiated and enabled again in its own default generated initiate code after the jump?
- Usually, this kind problem is cased by the VECT_TAB_OFFSET, but I am sure I defined it correctly in the system_stm32f2xx.c
- Why the same bootloader worked on the CubeIDE projects 3 years ago? but with the new IDE, I have to manually add the __enable_irq() in Application code? I am using STM32CubeIDE 1.13.2 now and not a big fan of it since I get lots of old projects cannot compile in this most up-to-date IDE. This was not happened in my past CubeIDE updates. Is this the problem also caused by the new behaviors and new libraries of this new IDE?
Thanks!
