STM32F767 IVT - relocation at run-time ?

[SGAUR.1]

Hello All,

I am working on a system and my firmware consists of a boot-loader (Second-Stage Boot Loader) and application. Boot-loader is occupying sector 0-3 and Application lies in sector 4 to sector 11 of micro-controller flash (STM32F767).

Problem statement : I want to further divide application flash area to hold two same applications files (e.g. application 1 : sector 4,5,6,7 and application 2: sector 8,9,10,11). These are same applications but I want to update one of these over the air and keep other as a back-up (reason : unable to extract board once installed)

Is there a way I can modify interrupt vector to start application from these sectors (sector 4 or sector 8  ? How do I update/modify 'VECT_TAB_OFFSET' to point IVT at sector 4 or sector 8 at run-time ?

Presently this macro is modified at compile-time.

Thanks,

Shriram

[Pavel A.]

You can write the address of the vector table to the SCB->VTOR register. Exactly as the initialization code that refers to "VECT_TAB_OFFSET" does. And you can edit it and remove the VECT_TAB_OFFSET macro for good.

This is the least part of your problem. Next, consider that the binary is not position independent. It can execute only at the address for which it is built. So you'll need to build the back-up app copy for a different address range or copy it to the address of the normal app.

[SGAUR.1]

Hello Pavel,

"You can write the address of the vector table to the SCB->VTOR register" - agree, but how do I perform this operation before systemInit() {this is where SCB-VTOR is updated} ?
Sequence wise -> I'm jumping from boot-loader and want to update this using some variables/argument (based on sector 4 or sector 8  app to start.

"you'll need to build the back-up app copy for a different address range" - I am trying to avoid same binary with different start address as circulating these two different copies will create nuisance in field. 

"copy it to the address of the normal app." - Yes, this is one of the option  (it's already implemented in one of our product). I'm okay with it but consider these few cases (worst case scenario):

a. if application is faulty/crashing, I will end up overwriting it to a good working application and board will not be recoverable. There is nothing to roll-back

b. I will be writing flash again (from received flash area) to working flash area. Potentially one additional write to flash. which I'm trying to avoid.
If I am able to figure out way to run same application from two different sectors (with some assembly instructions before systemInit() ?), it will give more flexibility to system.

Thank you for looking into it again.

Shriram

[Pavel A.]

> how do I perform this operation before systemInit() {this is where SCB-VTOR is updated} ?

Can be done after SystemInit call. Just add to your main() SCB->VTOR = ...

> consider these few cases (worst case scenario):

> a. if application is faulty/crashing, I will end up overwriting it to a good working application and board will not be recoverable. 

But there will be the bootloader itself? It can download a fixed app and recover the board?

[SGAUR.1]

"Can be done after SystemInit call. Just add to your main() SCB->VTOR = ..." - I will try this and update.
"But there will be the boot loader itself? It can download a fixed app and recover the board?" - Here is the catch. There are two installation of this product.

In one instance, you can connect to board through PC and update using boot-loader (direct link available, therefore no problem).
But in second instance, there is different board from vendor installed between PC and my board (and they communicate using proprietary protocol) and I cannot implement this whole custom protocol in boot loader, it's too heavy, therefore I've to receive new image in application mode itself and ensure, it's safe to update (In this case, If I stuck in boot loader with faulty image, unacceptable).

Thank you for your help. I'll try these solution and update.

Shriram

[Tesla DeLorean]

You should check the integrity of the firmware image before branching in to it.

If your code is otherwise address independent you can construct a relocated vector table in RAM and point SCB->VTOR at it. Watch the alignment, most need it to be on a 512-byte  boundary, depends on size.