STM32L49x and BFB2 bit

[Alekseus]

Hi everyone!

Just finished a dual boot system but during testing I bumped into a weird issue. With BFB2 bit unset firmware starts smoothly but when it is set, it ends up in some bootloader loop although it should switch to opposite bank (FB_MODE = 1) and run second firmware code. It looks like bootloader is waiting for update as it initialized I2Cs, CAN1 and USB.

System option word for this case is 0xFB7FF8AA (nBoot0 = 1, nSWBoot0 = 0, nBoot1 = 0, BFB2 = 1). Actual Boot0 pin is connected to ground (along with quartz generator). Initial stack values of both bank firmware are within SRAM range (it is mandatory to start firmware correctly).

What is most interesting, another board based on the same chip but slightly different on connected periphery works perfectly. It seems, the bootloader somehow disregards options and starts to check periphery to update but catches only noise (induced by unconnected pins or by sensor outputs) so it hangs.

Is there something I missed?

Regards

[Saket_Om]

Hello @Alekseus 

The boot source is determined by the option bytes `nBOOT0`, `nSWBOOT0`, and `nBOOT1`. while `BFB2` only has an effect when the MCU actually boots from Flash. If `nBOOT0 = 1`, the BOOT0 pin is disabled and its physical level is ignored; the effective BOOT0 value then comes from `nSWBOOT0` (with inverted logic). In the configuration `nBOOT0 = 1`, `nSWBOOT0 = 0`, `nBOOT1 = 0`, and `BFB2 = 1`, the resulting BOOT0/BOOT1 combination selects system memory, so the MCU enters the ROM bootloader, which initializes I2C/CAN/USB and waits for commands. Since the device is booting from system memory rather than Flash, `BFB2` does not affect which code is executed.

[Alekseus]

Thank you for your input but your conclusion contradicts Reference Manual (RM0351):

Moreover, as I mentioned in initial post, it works as intended just with BFB2 unset.

After I posted my issue, I found another post in Related Content links (https://community.st.com/t5/stm32-mcus-products/stm32l496-errata-es0335-dual-bank-boot-unable-to-reproduce/td-p/858369 ) which unfortunately I've never seen before. It contains actual answer I just checked: there is a quite ridiculous software bug in system bootloader which doesn't allow to have initial stack value in SRAM2 memory within 0x2004000 - 0x2004FFFF range. And what is more ridiculous - system bootloader in that case doesn't jump into bank 1 but hangs in with its own loop making the device totally inoperative without connecting debugger.