Rollback needed, do we really need dual boot banks?

[RBT-ES]

Hi all,

We want to make an application where users can update their devices. We want to rollback if the update failed. For this, we initially took a dual boot bank MCU, the STM32L471RG. But after being busy building a bootloader for it, I don't know if I really need dual boot banks.

I think I can get away with a single boot bank, and defining two blocks of memory as two possible app locations. The bootloader will decide which is the newest, and if it passes CRC check. Or does dual boot banks really makes this easier?

Some questions:

1. My bootloader lives at the start of the memory, should it live in both banks, if I would use dual boot bank?
2. How to swap banks?
3. What about memory offsets? Can we just flash a .bin file with any offset?
4. Does dual boot bank supports flashing the same .bin file in both banks without changing offsets?

[FBL]

Hi @RBT-ES 

1- In RM0351Table 8. Flash module - 1 MB dual bank organization, you can find bootloader addresses for each bank.

2/3/4- You can check the example firmware to swap banks using BFB2 option bit

STM32CubeL4/Projects/STM32L476G-EVAL/Examples/FLASH/FLASH_DualBoot at master · STMicroelectronics/STM32CubeL4 (github.com) 

[RBT-ES]

Hi, thanks for your reply.

Things are getting clear now. One question I have:

Address start of bank 1 is 0x0800 0000 and for bank 2 is 0x0808 0000. 

If I build my project with no memory offset, so it starts at 0x0800 0000, and flash it to 0x0808 0000, will this work?

Otherwise I have no point using dual boot, because I have to change the start address each time I change versions. That's what I also can do with my own bootloader.

[FBL · Accepted solution]

Hi @RBT-ES 

Using a bootloader can help manage this process by dynamically setting the VTOR and jumping to the correct application code depending on BFB2. So, you can flash your firmware to the second bank. Then, when BFB2 is switched upon reset, the MCU remaps the start address to 0x08000000, regardless of whether the firmware resides in bank 1 or bank 2.

[RBT-ES]

Thanks for your reply!

This is what I needed. Otherwise, I should patch the vector table, and I guess that's not a trivial task.