2020-02-05 06:49 AM
The bootloader is placed at 0x8000000 and the new application is at 0x08008000. I have attached images of the jump code and linker file.
2020-02-05 01:01 PM
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
APPLICATION (rx) : ORIGIN = 0x08008000, LENGTH = 896K
These two are overlapping, no idea what the linker makes out of this.
Double check addresses, the .map files, and verify the flash with st-link.
The bootloader disables interrupts and sets PRIMASK, will the application restore them?
Stock STM32 startup code sets SCB->VTOR in system_stm32f4xx.c, verify the offset there.
If all the above fails to cure the problem, follow the jump to the application in the disassembly window, see whether the code there is resembling startup_stm32*.s or it's complete junk.
Next time, please paste text in a code block instead of screenshots. Post the complete part number, STM32F4 has many variants.
2020-02-05 02:32 PM
> Stock STM32 startup code sets SCB->VTOR in system_stm32f4xx.c, verify the offset there.
Clive proposed a good patch for this.
Basically, patch system_stm32f4xx.c to always put to SCB->VTOR the address of the vector table, which is exported by the startup asm file (the name depends on compiler - gcc or Keil).
-- pa
2020-02-05 02:49 PM
Perhaps use the debugger?
Follow where it goes, determine where you enable the interrupts again in your app side code.
Have HardFault_Handler() and Error_Handler() output actionable data.
Avoid reinitializing the RCC (ie Clocks, PLLs) if already running.