From the ES0335 errata there are two errata that look pretty significant for dual bank boot (which I'm planning to use as the basis of field firmware update):
2.2.8 Dual-bank boot not working when the boot in flash memory is selected by BOOT0 pin
Description
When the nSWBoot0 option bit is set and the BOOT0 pin level is low, the dual‑bank boot does not work (BFB2
option bit = 1).
The user code is only executed when BANK 0 is valid.
Workaround
Do not rely on the BOOT0 pin to select the boot in flash memory. Instead, use the option bytes for that purpose,
setting the nSWBoot0 option bit to 0, the nBOOT0 option bit to 1, and the BFB2 option bit to 1. This setting allows
the correct check of the address 0 of the two memory banks, in order to execute from the correct one.
2.2.9 Dual-bank boot fails with stack pointer placed within aliased SRAM2
Description
If dual-bank boot is selected through option bits, the bootloader checks the contents of either flash memory bank
for validity. It considers a bank content valid if its first word (determining the stack pointer address) contains a
value from 0x2000 0000 to 0x2003 FFFF (SRAM1) or from 0x1000 0000 to 0x1000 FFFF (SRAM2). Any other
value is invalid.
As a consequence, the dual-bank boot fails if the first word of either flash memory bank points to a location within
the SRAM2 aliased at the address 0x2004 0000.
This limitation applies to STM32L496xx and STM32L4A6xx.
Workaround
Do not use aliased SRAM2 address range in conjunction with dual-bank boot.
To check these out I ported a test app I built for the STM32L475 (to which the above doesn't apply) and to my surprise it worked with no modification on a Nucleo-L496ZG.
The initial stack pointer in the image is 0x20040000 - which should apparently not work according to 2.2.9 above.
In the flash option bytes nSWBoot0 is set to 1 (the factory default), where 2.2.8 above suggests that I should need to set it to 0 to enable dual bank boot to work correctly. I have set BFB2 to using Cube programmer.
I verified that the Errata applies to my chip - according to Table 2. Device variants in the errata.
My test procedure is to
- Mass erase Flash
- Set BFB2 to 1 (and no other changes) in the User and read protection option bytes.
- Load my binary at 0x08080000 using Cube Programmer.
- Reset the board.
The test program detects which bank it is running from using
READ_BIT(SYSCFG->MEMRMP, SYSCFG_MEMRMP_FB_MODE)
0 means running from bank 1 (not swapped), 1 means running from bank 2.
If it detects it's running from bank 2 it erases bank 1 and copies itself to bank 1 then reboots, at which point it is running in bank 1.
I'm kind of surprised that it's working - I had expected to have to modify the initial stack pointer and set nSWBoot0 to 0, but none of that seems to be necessary.
I've also tried loading a different binary at 0x0800000 to see if the device still preferentially boots from bank2 when BFB2 is set.
So my conclusion is that maybe I don't understand the meaning of the two errata above. In what way does dual-bank boot not work ? Thanks in advance for any pointers.
