Who Sets the BFB2 Bit After Option Bytes Erase in STM32G4?

[JohnFrancis]

Hello, I am working with an STM32G4 microcontroller and noticed an unexpected behavior regarding Bit 20 (BFB2) in the User & Read Protection Option Bytes.

• According to the reference manual, BFB2 is a read-only bit.

• After performing an option bytes erase in Keil, I expected BFB2 to be cleared to 0 (default).

• However, after a system reset, I observed that BFB2 is set to 1.

I would like to understand:

1. Who sets BFB2 to 1 after an option bytes erase?

2. Is this controlled by bootloader behavior, internal flash controller logic, or some default hardware mechanism?

[TDK]

If you want BFB2=0, perhaps set it explicitly. There is no "option byte erase" procedure at the mcu level, so this is something Keil-specific being done.

[JohnFrancis]

In Reference Manual RM0440, the User & Read Protection Option Bytes are documented at Flash memory address 0x1FFF7800 with an ST production value of 0xFFEF F8AA. However, when I print the User & Read Protection Option Bytes, I get 0xFFFF F8AA, which does not match the documented production value.

I expected Bit 20 (BFB2) to be 0 (the default ST production value) because I had deleted the option bytes using Keil. I want to understand who sets BFB2 to 1, even though User & Read Protection Option Bytes are read-only.

I don’t necessarily want BFB2 to be 0, but initially, after deleting the option bytes, I checked and BFB2 was 0. Once the option bytes were properly set after the initial factory configuration, they were never configured again. However, now I can’t use that same logic to configure the option bytes.

[TDK]

Keil is setting those bytes. They do not change arbitrarily.

You can use STM32CubeProgrammer to set them if you'd like.