Bootloader + Flash partitions

[Wisnu Pramadi]

Posted on September 09, 2017 at 02:23

Hi,

I'm using STM32F469 which has quite a lot of flash space (2MB). I'm planning to place a bootloader to handle firmware upgrade and partitions the rest of the flash to store multiple firmware instances. Here are my setup:

Bootloader

@ 0x08000000 with size 128KB

Factory default app

@ 0x08020000 with size 640KB

Update app 1

@ 0x080C0000 with size 640KB

Update app 2

@ 0x08160000 with size 640KB

The idea is to place Bootloader and a factory default app in the flash by default. The bootloader already set the SCB->VTOR register before jumping and the factory default app has start address of 0x08020000 in the linker file like the following:

FLASH ORIGIN: 0x08020000 LENGTH: 1920K

The update 1 and 2 are for new firmware upgrade. I want the application to perform upgrade without entering the bootloader first. So update 1 will place the firmware upgrade on update 2 space when upgrading and vice versa (it's like doing ping pong). It will tell the bootloader which update is the latest one and the bootloader can jump to update 1/2 accordingly.

The problem is, I have to set the start address of the flash for each update to make it work. e.g.: I have to set the linker flash origin to 0x080C0000 if I want to place the update of update 1.

Is there any way I can skip the linker setting? or is there any way to tell the program that its start at certain address? I want the firmware update to be address independent (it can be placed either in update space 1/2) and it seems I have to set this linker statically for now.

Any though guys?

#linker #flash #bootloader #partitioning

[Tesla DeLorean]

Posted on September 10, 2017 at 00:12

The vector table contains absolute addresses. If you build address independent code you'll need to rebase the vectors in the table.

[Wisnu Pramadi]

Posted on September 11, 2017 at 02:51

Hi Clive,

I've set the vector table to the correct address right before jumping to the application. It's still not working if I set the memory map in the linker as 0x08000000 (default). I have to set this memory map according to the firmware location if I want to make it work.

[Tesla DeLorean]

Posted on September 11, 2017 at 03:01

That's not what I said, reread it, and don't insert the word SET.

[Wisnu Pramadi]

Posted on September 11, 2017 at 11:30

Hi Clive, after reading quite a bit I think I understand your point. I check the documentation and also the startup code, it enlist all the vector table entries. When I check the firmware's binary, I can see the first word is the _estack (the end of RAM address) and it follows by the vector table entries. After comparing code that are compiled with base 0x8000000 and 0x8020000, I can see those entries are given offset. I guess I have to rebase all these entries in the host (PC) before transferring to the MCU or in the receiving end of the MCU before I write the binaries to the flash.

I did a quick test by adding offset to these entries using hexedit (I edit the binary after compiled) but apparently it still doesn't work. My project use RTOS (FreeRTOS to be specific) and it seems that there are other entries that must be rebase other than the vector table content. Probably the stack of each tasks or the callback to the task itself (I don't really know which one). 

thanks for your clue on the vector table by the way. I'll check out the linker file and see if I can find any clue about the later problem. Also please let me know if you have any suggestion on that.

Wisnu

[Tesla DeLorean]

Posted on September 11, 2017 at 13:12

Provided the rest of the code in the image is 'address independent' one can either modify the vector table content as it is written, or use an area of RAM (512 byte aligned) where you can rebuild a new vector table with the base fixed-up (relocated), and then set SCB->VTOR to this RAM based table. This can be done with a loader that understands the images you have within FLASH.