Skip to main content
Z
zoranr
Associate
August 17, 2023
Solved

Dual bank execution from Bank2 (STM32L071)

  • August 17, 2023
  • 2 replies
  • 4273 views

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

zoranr_0-1692304046755.png

 

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

This topic has been closed for replies.
Best answer by zoranr

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;

 

 

2 replies

TDK
TDK
August 17, 2023

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."
F
FBL
Technical Moderator
August 18, 2023

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.


 

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.Best regards,FBL
Z
zoranrAuthorBest answer
Associate
September 3, 2023

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;

 

 

    Terms & ConditionsAccessibility statement