2026-01-19 4:03 AM
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
2026-01-19 5:06 AM
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.