Dual bank execution from Bank2 (STM32L071)

[zoranr]

Hi,

According to some of the on-the-fly firmware update documents, update is done with the following steps:

- program the new firmware to Bank2

- set BFB2 bit to start executing from Bank2

- while in Bank2, copy the code from active Bank2 to Bank1

- reset BFB2 to continue executing code from Bank1

Doing some small tests, I realized that it was fine to continue running new firmware in Bank2 until next firmware update is needed, without double programming and jumping Bank1 -> Bank2 -> Bank1. 

My question: Is there any disadvantage to continue executing new firmware from Bank2 until the newer firmware is available (and then programmed to Bank1)? Or is it really necessary to always run the main firmware from Bank1 (and use Bank2 just during the update)?

Note: I run tests with a simple program. Maybe I am missing some functionality which will not work on more complex programs on the long run executed from Bank2. Or my assumptions are just wrong. 

Thanks,

Zoran

[TDK]

From a performance standpoint, there are no issues with running in bank 2 indefinitely. The two banks should have identical behavior. And as you saw, you can boot from bank 2 by setting the appropriate option bits.

From a program logic standpoint, it might be useful to always run in bank 1 to make the update process the same each time, as opposed to having to figure out which bank you're in and program bits accordingly and make sure you erase the correct bank.

[FBL]

Hello @zoranr 

The two banks have similar behavior. The number of wait states depends on the voltage scaling range. Performance is almost linear in relation to the frequency. According to data retention, it depends on the number of program/erase cycles and temperature, not a specific bank.

[zoranr · Accepted solution]

After two weeks of further testing, I just wanted to provide additional feedback on this topic. We are running our main firmware alternatively on both banks, and there are no performance-wise differences or any additional code to verify which bank is being used. The FOTA update is the same, as it is always the 'other' bank being deleted and flashed.

However, the only deviation from a regular work flow is EEPROM. As it is also two-bank-based access, we are simply copying the EEPROM content from one bank to another during the OTA update.

One extremely important step is to always assign a vector table to 0x8000000 at the very beginning of the main code.

SCB->VTOR = 0x08000000;