Putting bootloaderversion into FLASH - first address before bootloader possible?

[Tobe]

Hi,

i want to store information about the bootloader into the FLASH. Since the size will vary during development, i wonder if its possible to put it before the bootloader.

If anyone knows about a good tutorial or video, i would be happy. I dont know what terms i should use to get this information.

 

 

[Pavel A.]

Not really. The vector table of a bootloader must be at certain address or at least have certain alignment. Put the version somewhere else.

[MM..1]

How bootloader you mean??? Your or system.

And one way exist place version on unused interrupt vector place ... but for what?

[Andreas Bolsch]

The very first word is reserved for initial stack pointer value. You could use this for a version number, but then the very first action in startup code should be (valid) initialization of stack pointer. As interrupts are disabled, the only risks are hard fault and NMI occurring before that. Quite low, I'd say, but ... One of the interrupt vector slots would be another possibility, but if you decide later to acually use this interrupt ... Right after the vector table comes with a risk if you later decide to use a different chip.

In general bootloader will be placed in the first page(s) of flash, and in order to erase the application without affecting the bootloader, one or several *full* pages must be reserved for the bootloader, so a better choice for version info would be the very *end* of reserved space for bootloader.

[Tobe]

From your answer, it seems to me, that a good place is after the vector table. I do not intent to use another microchip. I can add a few bytes after that, to possible leave room for a bigger vector table of another chip. Those few bytes would not hurt. I want to have this fixed address of the whole productlife. When i resize the bootloader so i can save or need another page, this would not work.

So for me at the moment, i see no problem with this procedure. What do you think?

[Tesla DeLorean]

There are unused fields in the vector table that could be safely used for all Cortex-M parts you're likely to encounter.

You can also wrap/package your updates with any kind of meta-data, compression, encryption and signing you might wish to implement.

[Pavel A.]

@Andreas Bolsch 

> As interrupts are disabled, the only risks are hard fault and NMI occurring before that. 

Except that FreeRTOS uses vectors[0] to reset the SP on start of the scheduler. But bootloaders typically don't have a RTOS - or the RTOS can be patched.

 

[moderation edited: removed answer to deleted AI spam]