Why does BFB2 (Boot From Bank 2) behave differently on 3 different STM32's ???

[AndyJT]

Is there (or have there been) some big issues with the BFB2 option and the STM32 Bootloader ?

I have been trying to implement firmware updating from our host by using the BFB2 option bit on three different STM32's and all of them behave differently:

STM32F469VIT6 (2Mb Flash)

Works as expected:

Load “Program A�? into 0x08000000

Load “Program B�? into 0x08100000 (Compiled and linked with same script)

Power up and “Program A�? runs

Turn on BFB2 and “Program A�? continues running

Power cycle and “Program B�? runs

Turn off BFB2 and “Program B�? continues running

Power cycle and now “Program A�? runs

STM32L476RG (1Mb Flash)

Works almost as expected:

Load “Program A�? into 0x08000000

Load “Program B�? into 0x08080000 (Compiled and linked with same script)

Power up and “Program A�? runs

Turn on BFB2, however, “Program B�? starts immediately meaning I can’t now tell the host the f/w update worked.

Power cycle and “Program B�? runs again

Turn off BFB2 and “Program A�? starts immediately

Power cycle and “Program A�? runs again

STM32L496RGT6 (1Mb Flash)

Does not work at all and keeps loading the STM Bootloader into 0x00000000 and filling the flash with unknown codes.

Load “Program A�? into 0x08000000

Load “Program B�? into 0x08080000 (Compiled and linked with same script)

Power up and “Program A�? runs

Turn on BFB2, however, “Program B�? does not start but the STM32 Bootloader immediately runs and performs weird operations like turning on Protection of BankA and wiping 0x08000000 with seemingly random numbers. I think it's the STM Bootloader running as the Vector table values at 0x00000004 onward are all 0x1FFFxxxx type numbers.

Has anyone any advice please ?

Or do we just have to try stick to the micro that works for us ?

Thanks.

[Bubbles]

Hello @AndyJT​ ,

the BFB2 or generally the way the dual bank works has changed multiple times, it's constantly evolving. I haven't tried but the difference between the first two cases looks like a matter of OB reload triggering a reset on the L476. It's however possible to flip the BFB2 without reset on L476, I tried that in the past.

I haven't personally tried dual bank on L496. You write compiled and liked with the same script but... Isn't it easier to simply use the identical binary for such test? And load it twice using for example CubeProgrammer?

BR,

J

[AndyJT]

Hi thanks for the answer.

If you could remember some more details of how to stop the L476 from triggering reset when the BFB2 is flipped, would be great!

If the reset can be turned off we can probably swap the L496 for the L476.

As for the L496, I've tried the exact same binary in both banks using STLink Utility, even tried loading to 0x08040000 instead of 0x080800000.

Even when it wasn't the same binary, it was the same basic code - just a change to the PCB LED flashing speed. It was only a basic "blinky" app with clock config, gpio setup and an eternal loop to flash the LED.

It's pretty frustrating that I spent quite a bit of time implementing f/w update from our host PC application on the F469, only to find that the function of BFB2 is different (broken?) on the next project using L496 and will now need either a PCB redesign with HAL re-code, or some other difficult solution like FB_MODE which requires consistent, unmodifiable code on start-up, and some way of knowing which bank it should be running from.

Thanks

[Tesla DeLorean]

Yes, I think "evolving" is a bit disingenuous, it's more like it was badly thought out and executed by people with little real-world experience of what's needed and also not burdened with the consequences of it not working properly/desirably.

I don't know who thought it would be a good idea to involve the system loader in a basic task of reading the vector content to establish a blank device. Or those who made the process of running the ROM code so convoluted it would call back the user code when the specific need was to start/run the ROM loader for the USB or UART methods to work.

Personally I think a simple bank switch mechanism, a handful of independent option bits and a common boot loader could more readily determine the integrity of each image, age/sequence number, and finally a forking bank switch.

[AndyJT]

Good comments and I agree. How did it get so complicated ?

Someone thoughtfully created the Bfb2 option bit and the clue is there in the name: Boot From Bank2

If it's set, run code from bank 2 after next reset

If it isn't set, run code from bank 1 after next reset

Why would anyone then think its a good idea to reset as soon as you set the bit?? Surely it's up to the user to call HAL_NVIC_SystemReset() if that's what they want to happen.

​Still at a loss for the best way forward though.

Looks like we're going to be releasing some products that can only be updated by taking them apart and connecting a programmer :(

[MHAJJ · Accepted solution]

Hello,

Here my thoughts on this, the difference in behavior between F4 and L4 is in the option bytes programming, in the L4 Setting OBL_LAUNCH generates a reset (RM0351 page 117) while the F4 option byte programming does not require (RM0386 page89), I think it may be interesting to test for L4 case without executing  HAL_FLASH_OB_Launch(); as you have a power cycle in your sequence anyway (the update of the option byte will take effect at this step and then will boot program B).

As for the differences in behavior between L476 and L496, please check RM0351 table 4 for STM32L476 and table 6 for STM32L496, these are the boot modes and maybe you can find a difference there depending on your option bits and pin configuration.

Hope this help.

Regards,

Hajji.

[AndyJT]

Hi,

Many thanks for the answer.

You are correct, the L476 does not reset if I remove the call to HAL_FLASH_OB_Launch()

I think the comment from the example code maybe a bit misleading here as the BFB2 option change is remembered after a hard reset without calling HAL_FLASH_OB_Launch()...

/* Start the Option Bytes programming process */  
if (HAL_FLASH_OB_Launch() != HAL_OK)
{
	/* User can add here some code to deal with this error */
	while (1)
		{
		}
}

I also found that it may be possible to change bits you didn't mean to, so set the OptionType and USERType for the HAL to mask the BFB2 bit:

	HAL_FLASHEx_OBGetConfig(&OBInit);
	OBInit.OptionType = OPTIONBYTE_USER;
	OBInit.USERType =   OB_USER_BFB2;
	if (((OBInit.USERConfig) & (OB_BFB2_ENABLE)) == OB_BFB2_ENABLE)
	{
		OBInit.USERConfig &= ~OB_BFB2_ENABLE; 	// turn on BFB2
		HAL_FLASHEx_OBProgram(&OBInit);
	}
	else
	{
		OBInit.USERConfig |= OB_BFB2_ENABLE; 	// turn off BFB2
		HAL_FLASHEx_OBProgram(&OBInit);
	}

So, I got the STM32L476 working as I wanted it now.

However, it seems that any and all combinations of the STM32L496 boot modes cause strange things to happen. I will look into that device again when I get more time.

Regards,

Andy