STM32G070RB: Inconsistent FLASH_ACR EMPTY flag after full erase (REV_ID 0x2000 vs 0x2001)

[tdenis]

Hello everyone,

I'm observing inconsistent FLASH ACR EMPTY flag behavior on two STM32G070RB chips (DEV_ID 0x6460) after a full chip erase by using STM32CubeProgrammer]

Observed behavior:

STM32G070RB (REV_ID 0x2000): After full erase, FLASH_ACR EMPTY flag correctly sets to '1' (chip boots into system memory). This is the expected behavior.

STM32G070RB (REV_ID 0x2001): After full erase, FLASH_ACR EMPTY flag remains '0'. The chip attempts to boot from main Flash (0x08000000) despite being empty, leading to unexpected behavior.

Questions: 

Is there a documented difference in the Flash empty check mechanism or FLASH_ACR EMPTY flag behavior between STM32G070RB REV_ID 0x2000 and REV_ID 0x2001?

Are specific option byte settings or erase sequences required for REV_ID 0x2001 to correctly assert the EMPTY flag after a full erase? (I have tried power cycling.)

Thanks,

Tomislav

[STOne-32]

Dear @tdenis ,

Can you please check our AN2606 : Introduction to system memory boot mode on STM32 MCUs - Application note 

Table 99. STM32G07xxx/08xxx bootloader versions , we have a known limitation that impacts Bootloader V11.3 and fixed in V11.4 

45.3.1 Compatibility break on boot sequence
Some enhancements introduced in V11.3 break the compatibility with the boot sequence of versions V11.2 and V11.1.
The major change is the addition of initialization of hardware peripherals (for the exact list refer to Section 45.1) used by the bootloader to their default values (as defined in RM0444).
The main impact is seen in two cases:
1. When jumping to the bootloader from user flash, the first operation is to reset the peripherals to their default values.
2. Usage of the “Empty check” boot mode
– Empty check flag is raised by HW on a POR or option byte change when the user flash is empty.
– This detection leads to boot on the bootloader.
– As per the new boot sequence, the bootloader clears this flag.
– Using a reset while the user flash is not yet programmed leads to a wrong boot on an empty user flash.

Avoid resets (except POR or option byte change) while the user flash is not programmed by the bootloader.

If possible to read by the STM32CubeProgrammer your bootloader version and check if this is root-cause of such behavior .

Hope it helps you

STOne-32.