Best practice keeping track of banks for OTA rollback

[Southbranch]

Let say there are two separate flash banks defined in the linker script, Bank 1 and Bank 2.

The current application version executes in Bank 1, and in Bank 2 the previous version is stored.

When the bootloader identifies a new version, for example on a SD-card, the previous version is erased and flashing is made into Bank 2. If all goes well (checksum etc) the bootloader then sets this version as the current version and makes a memory jump to start this version in Bank 2. However if things goes wrong, it jumps back to previous version in Bank 1.

At pre-build time, the active flash bank needs to be set in the linker script and the VTOR pointer needs to be aligned with the memory address to this bank.

Now, what is the best practice to keep track on which bank to use on pre-build time?

[Tesla DeLorean]

A lot of requirement I see need to provide for a sequence number, so you can see/find the latest image, and preclude reversion. This could arguably be a function of build time, rather than just an increment, but needs to advance so as not to allow regression to an earlier firmware with vulnerabilities.

You're supposed test and QA distributed FW prior to deployment, so shouldn't be flawed in basic ways. Could be more subtle issues, but should be able to at least limp-home, or pull an available update.

This doesn't mean you can't rollback to the last know working if you've tested the crc/signing on the new(er) image and that fails integrity checks.

[Southbranch]

Many thanks for pointing out these aspects.

I guess a reliable long-term solution could be be to keep a server based tracker for respective banks, versioning etc 

To begin with I will just do manual tracking of respective Banks and versions at pre-build time. 

 

[Southbranch]

A follow-up on my own question and previous answer:

• What about putting all Bootloader logic into App1 and App2 and let these apps manage the entire handover and all other aspects that comes with it? (by other words, no separate Bootloader app)

In theory this seems to offer an easier setup to manage over time - drawbacks?