Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post here all questions related to STM32 core if you can't find a relevant section!
Post Reply
kjn
Posts: 8
Joined: Wed Apr 15, 2020 4:21 am

Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by kjn »

Hi,

So I have an interesting problem. I have a F103 module, which we have a custom (CAN based) bootloader, which is written in STM32CubeIDE. I would like the option of writing code using the STM32dunio core, mostly for library/peripheral testing, but also much quicker to bring code online.

The jump from our bootloader is a pretty standard approach, and usually in our application (written in CubeIDE) we can just make sure the vector table is relocated at the start of the application:

Code: Select all

SCB->VTOR = 0x08002800U;
I've tried a few different approaches using the STM32duino core (2.3.0), but have yet to have success. It looks like the application is crashing on start-up. Reading further into the core:

from system\SMT32F1xx\system_stm32f1xx.c:

Code: Select all

/* Note: Following vector table addresses must be defined in line with linker
         configuration. */

/*!< Uncomment the following line and change the address
     if you need to relocate your vector Table at a custom base address (+ VECT_TAB_OFFSET) */
/* #define VECT_TAB_BASE_ADDRESS 0x08000000 */

/*!< Uncomment the following line if you need to relocate your vector Table
     in Sram else user remap will be done by default in Flash. */
/* #define VECT_TAB_SRAM */

#ifndef VECT_TAB_OFFSET
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */
#endif

#ifndef VECT_TAB_BASE_ADDRESS
#if defined(VECT_TAB_SRAM)
#define VECT_TAB_BASE_ADDRESS   SRAM_BASE       /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#else
#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#endif /* VECT_TAB_SRAM */
#endif /* VECT_TAB_BASE_ADDRESS */

...

 /* Configure the Vector Table location add offset address ------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
I thought just adding the two lines to the start of our sketch (blink.ino):

Code: Select all

#define VECT_TAB_OFFSET         0x00002800U
would be sufficient, but still I can't get it to work.

I am using the "Export Compiled Binary" option to generate a BIN which we load into our bootloader host application for transmitting to the target.

Any idea why this isn't working and/or what additional defines I need to add to the sketch to get the Vector table to jump appropriately when using this core?

Cheers
fpiSTM
Posts: 1838
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 102
Location: Le Mans
Contact:

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by fpiSTM »

Define it at sketch level is not correct as it is a cpp file and so define is not populated.
You should use the build_opt.h feature:
https://github.com/stm32duino/wiki/wiki ... uild_opt.h

Unfortunately, I've introduced a regression with this feature:
https://github.com/stm32duino/Arduino_C ... ssues/1749

You have to manually apply the patch in the system/extras/prebuild.sh.
Then in build_opt.h add:

Code: Select all

-DVECT_TAB_OFFSET=0x00002800U
kjn
Posts: 8
Joined: Wed Apr 15, 2020 4:21 am

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by kjn »

Good answer! Thank you.

Is there a way I can verify that this define/instruction was passed correctly? Inspect the hex/bin or the output?

I am still getting an application non start.
fpiSTM
Posts: 1838
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 102
Location: Le Mans
Contact:

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by fpiSTM »

Simply edit this file system\SMT32F1xx\system_stm32f1xx.c and add some extra characters between the #ifndef.
If it does not failed to build then this mean it is well redefine. But I have no doubt it is well redefined.
kjn
Posts: 8
Joined: Wed Apr 15, 2020 4:21 am

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by kjn »

fpiSTM wrote: Thu Jun 30, 2022 11:57 am Simply edit this file system\SMT32F1xx\system_stm32f1xx.c and add some extra characters between the #ifndef.
If it does not failed to build then this mean it is well redefine. But I have no doubt it is well redefined.
after patching as mentioned and making a "build_opt.h" file...

I was able to verify the compilation and execution vector jump, but poking the register with CubeProgrammer after the bootloader times out.
However my Arduino application still crashes and heads back to bootloader before it does anything (at the moment its just Blink on PB2).\
NB: It just crashes and doesn't head back to bootloader if I have IWDG disabled in the BL.

I've disabled the watchdog in the BL, copied the clock configuration block from the working blink application (in Cube) into the sketch (with exern "C") as the clock config is quite different.

What else could stop my program from running? The bootloader jump is basically the same as the HID bootloader (and as mentioned works with a Cube compiled application)

If anyone could check my work that would be very much appreciated!

Here is the Application Jump in the BL:

Code: Select all

void jump_to_application(){
    void (*main_code)(void);
    volatile uint32_t * appl_address = (uint32_t *) (MAIN_PROGRAM_START_ADDRESS_LD);
    HAL_CAN_DeInit(&hcan);
    for(IRQn_Type i = 0; i < 42; i++){
        HAL_NVIC_DisableIRQ(i);
    }
    // Disabling SysTick interrupt
    SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;
    // booting really
    SCB->VTOR = (volatile uint32_t)appl_address;
    appl_address++;
    main_code=(void(*)(void))*appl_address; //give address stored in pointer
    main_code();
}

Edit: Here is the functional CubeIDE main.c and the non-functional blink.ino + build_opt.c (in a zip due to forum restrictions).
Attachments
main.zip
(1.92 KiB) Downloaded 320 times
Blink.zip
(1016 Bytes) Downloaded 279 times
kjn
Posts: 8
Joined: Wed Apr 15, 2020 4:21 am

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by kjn »

fpiSTM wrote: Thu Jun 30, 2022 11:57 am Simply edit this file system\SMT32F1xx\system_stm32f1xx.c and add some extra characters between the #ifndef.
If it does not failed to build then this mean it is well redefine. But I have no doubt it is well redefined.
So I think I need to specify the application offset in the memory region of the linker:

Code: Select all

/* Memories definition */
MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = LD_MAX_DATA_SIZE
  FLASH    (rx)    : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET
}
Can I do this with build_opt.h?

-DLD_FLASH_OFFSET = 0x2800?

I've tried this and it doesn't work as expected.
fpiSTM
Posts: 1838
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 102
Location: Le Mans
Contact:

Re: Vector Table Relocation -or- Use of a 3rd Party Bootloader

Post by fpiSTM »

Hi,

you are right. I forgot to mention the LD_FLASH_OFFSET.
Anyway, I don't think you could redefine it using build_opt.h as it is not used for this part.
You should use the boards.local.txt:
https://arduino.github.io/arduino-cli/0 ... dslocaltxt

Like this you could simply add a new entry for your board with the correct option, example:

Code: Select all

3dprinter.menu.pnum.PRNTR_V2.build.flash_offset=0x8000
3dprinter.menu.pnum.PRNTR_V2.build.st_extra_flags=-D{build.product_line} {build.enable_usb} {build.xSerial} -DVECT_TAB_OFFSET={build.flash_offset}
Pay attention with the last release 2.3.0, build_opt.h has a regression preventing to kept user define:
https://github.com/stm32duino/Arduino_C ... ssues/1749

it is fixed in the main branch.
Post Reply

Return to “General discussion”