Issue when setting Vector table register

[Scott Dev]

Posted on April 30, 2018 at 17:56

Hi

  I have a booloader application that loads in new firmware in a different part of the flash. After updated I reset the processor and the newly uploaded application doesnt start. I think I must not be updating the vector table correctly because if I simply use the same vector table as the bootloader it works (the small uploaded test application doesnt use interupts). Here is my code in the bootloader.

#define APPLICATION_ADDRESS  (uint32_t)0x08002030

typedef  void (*pFunction)(void);

int boot_NewApp(void)

{

     pFunction JumpToApplication;

    uint32_t JumpAddress;

    // Get the application stack pointer (First entry in the application vector table)

    JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);

    // Get the application entry point (Second entry in the application vector table)

    JumpToApplication = (pFunction) JumpAddress;

    // Reconfigure vector table offset register to match the application location

   SCB->VTOR = APPLICATION_ADDRESS;

    // Set the application stack pointer

     __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);

    // Start the application

     JumpToApplication();

    while(1);

}

If I comment out the 'SCB->VTOR = APPLICATION_ADDRESS;' line, it works as expected by using the bootloader vector table.

Can anyone please let me know what I am doing wrong?

Regards

Scott

[Tesla DeLorean]

Posted on April 30, 2018 at 18:35

>>Can anyone please let me know what I am doing wrong?

Got a bunch of random interrupts firing?

Stepped into with a debugger? Learned what?

[Scott Dev]

Posted on April 30, 2018 at 18:37

Hi

    I added the line __disable_irq() at the start of the above function, and added __enable_irq() in my new application, and seemed to work okay until I added a serial interupt , and my bootloader vector table is used. Any idea why this is? I re added the SCB->VTOR = APPLICATION_ADDRESS; line in my bootloader..

Best Regards

Scott

[Tesla DeLorean]

Posted on April 30, 2018 at 19:00

 ,

 ,

Really the interrupts need to be culled at the peripheral level, especially when the app image doesn't support given interrupts, or statics haven't been initialized yet. Watch for SysTick in HAL implementations.

Have a proper Hard Fault Handler on both Loader and App, this should output to a USART ideally so death here can be quickly diagnosed.

Something in Default_Handler might also help if there is a disparity between IRQ Handlers provided by Loader and App

 ,

[waclawek.jan]

Posted on April 30, 2018 at 19:09

#define APPLICATION_ADDRESS  (uint32_t)0x08002030

[...]

    // Reconfigure vector table offset register to match the application location

   SCB->VTOR = APPLICATION_ADDRESS;

You didn't care to tell us what STM32, so I assumed Cortex-M4:

JW

[Scott Dev]

Posted on April 30, 2018 at 19:54

Im using a STM32L073 chip.

Thanks

Scott

[waclawek.jan]

Posted on April 30, 2018 at 23:11

Im using a STM32L073 chip.

And then how hard is it to look it up in the respective Cortex-M0+ Programming Manual?

So, adjust the position of the table accordingly to the given granularity of 128 bytes.

JW