cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H563 Application boots only with manual linker/VTOR edits, fails when generated via CMake:

ak52
Associate III

I am working on an STM32H563 project with a custom bootloader and two application slots (APP1 / APP2).

This is my memory layout

  • Bootloader: 0x08000000
  • APP1: 0x08022000
  • APP2: 0x0806C000

The bootloader is already deployed in the field and cannot be modified.
The bootloader jump sequence is standard:

  • Validate application
  • Set SCB->VTOR = APPx_START_ADDRESS
  • Load MSP from APPx_START_ADDRESS
  • Jump to reset handler at APPx_START_ADDRESS + 4

 

This works perfectly when I build the application the “manual” way:

  • Manually change FLASH ORIGIN in the application linker script to 0x08022000
  • Manually change VECT_TAB_OFFSET in system_stm32h5xx.c
  • Then i ReBuild → flash → bootloader jumps and application runs correctly.

I would like to automate this process using cmake , without manually editing the linker script and system_stm32h5xx.c

So I implemented:

  • A parameterized linker script template (STM32H563xx_FLASH.ld.in)
  • CMake configure_file() to generate slot-specific linker scripts
  • CMake target_compile_definitions() to inject VECT_TAB_OFFSET
target_compile_definitions(app1 PRIVATE
    VECT_TAB_OFFSET=0x00022000
)

In the linker template .ld.in file, i have this:

MEMORY
{
  RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 640K
  FLASH (rx)  : ORIGIN = @FLASH_ORIGIN@, LENGTH = @FLASH_LENGTH@
}

FLASH_ORIGN and FLASH_LENGTH are the variables

The generated .ld correctly shows FLASH (rx) : ORIGIN = 0x08022000, and i checked using STM32 cube programmer that the hex file is programmed at the correct address.

 

The problem is that when i generate the hex files from cmake , once i flash them in , the bootloader does not jump to the application.
Am i missing any obvious step here? I have attached the cmakelist file and the linker template(STM32H563xx_FLASH.ld.in)
Kindly Help

1 ACCEPTED SOLUTION

Accepted Solutions
gbm
Principal

The common reason for that kind of failure is the unreasonable setting of VTOR in SystemInit() routine.

The easiest fix is to put the statement at the very start of main():

extern struct cm_vectable_ g_pfnVectors;

SCB->VTOR = (uint32_t)&g_pfnVectors;

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

View solution in original post

2 REPLIES 2
gbm
Principal

The common reason for that kind of failure is the unreasonable setting of VTOR in SystemInit() routine.

The easiest fix is to put the statement at the very start of main():

extern struct cm_vectable_ g_pfnVectors;

SCB->VTOR = (uint32_t)&g_pfnVectors;

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
ak52
Associate III

Thanks , Once i manually set the SCB->VTOR in main , i am now able to jump properly.