BFB2 and bootloader flash-bank selection

Posted on February 23, 2016 at 18:15

I've recently delved into this subject because I need to design a firmware upgrade mechanism on the STM32L4xx.  The documentation is pretty much useless, as it is not only incomplete, but contradictory too.  I'm guessing the guy/gal who wrote that section of the Reference Manual wasn't sure how it worked either.  The only prose description is the following passage from section 2.6:

When booting from the main Flash memory, the application software can either boot from

bank

1 or from bank 2. By default, boot from bank 1 is selected.  To select boot from Flash memory bank 2, set the BFB2 bit in the user option bytes. When this bit is set and the boot pins are in the boot from main Flash memory configuration, the device boots from system memory, and the boot loader jumps to execute the user application programmed in Flash memory bank 2. For further details, please refer to AN2606.

The string ''BFB2'' does not appear in AN2606.  There is a ''dual bank boot'' flow chart (figure 55), but it seems to indicate that the decision to boot from bank 1 or bank 2 depends on whether ''the value of first address of bank 1/2 is within internal SRAM address''.  I must be missing something fundamental, as I don't see what any of this has to do with SRAM...

I know this topic has come up before, but I am still not clear on what, exactly, the BFB2 bit does:

1) Does it select which bank to boot from, as the ref manual seems to imply in one place, or does it merely put the system in a mode where you can select the bank using some other mechanism, as AN2606 (and the register description itself) implies?  And if the latter, how do you choose the bank to boot from?

2) When booting from bank 2, is flash memory actually remapped so that bank 2 appears at the bank 1 address and bank 1 appears at the bank 2 address?  Or does the bootloader merely jump into bank 2 instead bank 1?  In other words, must I build relocatable code and set VTOR, or not?  I find nothing in the ST docs to suggest a hardware-level remapping, but a previous comment by clive suggested it.

It would be nice to clear this up once and for all, since ST don't appear to be fixing their documentation.  (Search hits in this forum were from 2013 and 2014.)