For STM32G4xx, please clarify role of BFB2 in option bytes

[waclawek.jan]

If BLB2=1, hardware maps the System memory to address 0. The bootloader might've remapped it when it detects "valid code" in either bank, but it apparently does not do it, as witnessed by footnote to SYSCFG_MEMRMP.MEM_MODE description:

1.When BFB2 bit is set, the system memory remains aliased at @0x0000 0000

IMO, this should be added - maybe also as a footnote - to Table 5. Boot modes.

The reason is, that the combination of default VTOR=0 and System memory mapped at 0 causes the users to complain of "my code crashes at 0x1fffxxxx", which we see here quite often.

---

SYSCFG_MEMRMP.MEM_MODE description is common for all three Cat devices; however, the BFB2 bit is present only in Cat.3 devices according to in which Flash chapter is it present at all. Shouldn't this fact be reflected in the abovementioned footnote?

---

Only Cat.3 devices are documented to have BFB2 in option bytes. However, factory-progrmmed value for Cat.2 and Cat.4 devices have the bit at this position set to 0, which is surprising (as the default values for reserved option bits are systematically 1, the erased FLASH bit state). Does this have any pertinence to the above comment? Can please the fact that this bit has to be 0 at all times be highlighted in the Cat.2 and Cat.4 option bytes description?

---

Also, RM0440 for the Cat.3 'G4 says:

Supports dual boot mode thanks to the BFB2 option bit (only in dual bank mode)

(emphasis mine). So, for the process you've described to work, is it necessary to program also to have DBANK=1, or will it work also when BFB=1 and DBANK=0?

---

It would be also nice, if AN2606 would be clear about what does "valid code" (and "Flash memory empty" in case of Patterns 6, 11, 13) exactly mean. I know the information is out there, if one searches well, but it would be nice to see it at the description of the Patterns, maybe as a footnote; or alternatively in the individual devices' chapters.

JW

[Igor Cesko]

Hello waclawek.jan ,

You are right that if BFB2 is set then embedded bootloader maps address 0x0000 0000 to bootloader itself. Then next jump to user code can leads to errors if application assumes that VTOR=0. It is necessary to always rewrite VTOR to customer interrupt table.

This behavior is observed in customer application - we will try to improve this practical case (BFB2=1) description in next release of RM0440 (only for devices with dual bank).

Regarding the devices without dual bank: there are no dependency from BFB2 bit. This bit is not present there.

If dual bank device set DBANK=0 and BFB2=1 : need to test this strange configuration. I think this will have no effect (but need to test). If DBANK=0 then both Flash banks are grouped into one memory blocks with wider bus access to Flash (128-bit access) - each even 64-bits from Bank1 are interlaced with odd 64-bits from Bank2 (interlaced).

Regards

Igor

[waclawek.jan]

Thanks, Igor.

Jan