Bootloader entry on STM32G07x

[Konami]

Hi all, I'm experiencing a strange issue where every once in a while I am unable to enter bootloader on the STM32G0. I have the option bits set correctly and have a hardware push button connected to both nRst and Boot0. I can normally hold the Boot0 button while toggling reset to enter the ST bootloader in ROM. However, every once in a while I enter a state where no matter how many times I reset, or the state of the BOOT0 pin, the device will boot into my application instead of the ROM. The only way to recover seems to be to fully power down the device, after which the bootloader entry continues to work as expected.

It is reproducible on brand new (blank) parts. They enter bootloader by default but after that aren't able enter bootloader by toggling BOOT0 until a power cycle. Outside of that, I haven't been able to deterministically reproduce it, but it does periodically enter this state.

Some notes that may be relevant

• The application sets the OB to use BOOT0 to enter the ROM
• The random occurrences of this state seem to be correlated with using the ST-Link
• I suspected the SWCLK and BOOT0 sharing a pin as the issue (ie. pin is being reconfigured as an output), although this does not explain the blank flash case, or why hardware reset doesn't recover

Any ideas what this might be or how to debug/resolve?

[TDK]

The bootloader and the startup sequence is in ROM and isn't prone to erratic behavior. I would suggest methodically testing, staying objective.

Blank devices will always boot to the bootloader due to an empty flash check--no surprise there.

Having ST-Link connected during boot is going to control the BOOT0 pin, so you'll need to go the option byte route if you want to choose what should load.

[Konami]

Okay, I did some more digging and this is reproducible on a NUCLEO-G071RB. See steps below

Configure option bytes using STM32 Cube Programmer:

1. nBOOT_SEL = Unchecked
2. nBOOT1 = Checked
3. nBOOT0 = Checked

Reproduce expected behavior:

1. Flash blinky app to Nucleo to indicate application is running. Remove USB connection
2. Configure Nucleo 5V to VIN on JP2 and supply 5V externally
3. *** LED Blinks ***
4. Short PA14/BOOT0 (Pin 7 on CN7) to 3V3 and press reset button
5. *** LED does not blink because we are in ROM BL ***

Reproducing breaking behavior. Starting from step 5 above:

1. Plug in micro USB
2. *** ST-Link takes over BOOT0 pin and runs application; LED blinks ***
3. Unplug micro USB
4. Press reset button
5. *** LED continues to blink even though it shouldn't ***

At this point you can reset the board as much as you want, it will not go back to the ROM. If I disconnect the external 5V and reconnect it, everything starts working again. Is this expected behavior? This debugger cycling obviously isn't a common use case, but I have observed these same symptoms without connecting an ST-Link at all, leaving the G0 in an unrecoverable state until a full power cycle.

[Tesla DeLorean]

One of the protection mechanisms against glitching attacks is to latch boot and option bytes at power-up. This means that a Reset doesn't clear them, only a proper power cycling.

[Konami]

I'm not trying to change the bytes though. I set them once and then keep them the same. All I'm doing is powering up and the powering down the ST-Link on board the Nucleo. Is there anything else that latches?