Boot on QSPI => VTOR change in BOOT or APP firmware ?

[COSEBE]

Hi,

Can someone clarify why some examples of boot to QSPI change the SCB->VTOR register in JumpApp function :

SCB->VTOR = (uint32_t)Application_vector;
JumpToApp = (pFunction) (*(__IO uint32_t *)(Application_vector + 4u));
__set_MSP(*(__IO uint32_t*) Application_vector);

And some examples change the SCB->VTOR register in void SystemInit(void) function:

SCB->VTOR = 0x90000000;

I think both works but is there a best way and can someone explain the advantage and the inconvenient to update VTOR register in BOOT project or APP project.

[Tesla DeLorean]

>> Do you know why ?

Does it matter?  ST has historically set it in SystemInit(), via a bunch of #defines

Disabling the MCU IRQ, and where the table changes shouldn't be important. You shouldn't have interrupts firing. If you point at the new vector table, all the RAM and peripheral instances are completely out of context. And they way the HAL/CUBE examples work the status-quo won't be resolved until deeper into main()

What you should be doing is tearing down all interrupts / peripheral so the hand-over is clean