Is BFB2 broken in STM32F429BIT6 bootloader?

[Low Level Driver]

• Have BOOT0 pin strapped low
• Firmware image is linked to run from address 0x08000000, initial stack pointer
• Initial stack pointer is set at 0x2002FFFC.
• Programmed firmware image to 0x08000000.
• Processor boots fine when BFB2=0 in option bytes
• Bootloader fails to enter the firmware image in Flash when BFB2=1 and bootloader is loaded to address 0x00000000.

From AN2606, the bootloader firmware should examine 0x08100000 for a stack pointer into SRAM, then 0x08000000 for the same. It doesn't seem that this is happening, though. Is there a good way to debug this further?

[Tesla DeLorean]

>>Is there a good way to debug this further?

Output internal state from within.

Dump two locations, and OB / FLASH / SYSCFG registers.

Should swap banks, so both should be built for 0x08000000 operation as I recall.

Check vector content meet expectations.

Could create a small loader/monitor in first 16KB of each bank, and then map/fork from there.

You should check ROM system loader version. Might be errata, or other expectations.

With thought you could run the debugger through the ROM code, and watch what it does and why.

[Low Level Driver]

Thanks Tesla DeLorean...

• Setup a new simple project with STM32CubeIDE with a main function that just reads LL_SYSCFG_GetFlashBankMode() and sets GPIO to indicate running Flash bank.
• Generated binary and used ST-Link/V2 to load the same image into both flash banks.
• Used debugger via STM32CubeIDE and ST-Link/V2 and observed that the system was getting kicked back into the Reset_Handler over and over again.
• Finally figured out that the system gets kicked back to the Reset_Handler when the system tick interrupt fired! Maybe the vector table is wonky?
• Uncommented "#define USER_VECT_TAB_ADDRESS" in system_stm32f4xx.c to find the vector table at the FLASH_BASE address. 😁 Works!