STM32G0B1 Options Bytes

[YDann.7]

Dear,

I currently use a STM32G0B1 on a custom board ans all worked fine until now.

My firmware change the options bytes at running to disable the dual bank and using and single bank Flash.

At the power up, the firmware check the options bytes and change the value if needed.

To do some test, I used the STM32CubeProgrammer to resetting the options bytes to their default value. And now, I'm not able to connect to the MCU and the MCU seems to not running.

How can I unbrick the MCU ?

[Hdd]

Which options have you changed, please? Have you checked the SWD connection, the Reset, your Stlink tool, the Vcc?

[YDann.7]

I change the "DUAL_BANK" bit.

At running time, I changed it to used a single bank flash.

Before resetting options byte, it's was as on the photo. I just enable the "DUAL_BANK" bit and after that, i'm not able to connect to the MCU.

On the SWD connector, the 3,3V is ok and the NRST pin is high (so ok too).

[Hdd]

can you force the boot0 to boot to the main flash for you board a with a jumper and see if you can connect.  you can find some information about STM32 boot here: FAQ STM32 boot process - STMicroelectronics Community

[YDann.7]

Boot0 pin is shared with SWCLK so I won't be able to use a ST-link probe to connect to the MCU (but I can do the test).

And by default on STM32G0, the Boot0 pin is not used. you must change the options bytes to use the Boot0 pin as legacy mode. But I didn't change this options bytes.

[YDann.7]

OK, I tried to force boot0 pin to to boot the the main flash but same result. I'm not able to connect to the MCU.

I also tried to force the boot0 pin to boot on the system memory and same result.

For me, it's a right result because the boot0 pin isn't used as legacy mode.

Really strange if it's possible to brick the MCU just by changing the options bytes.

[Simon.T]

Hello @YDann.7 ,

Can you confirm the REV_ID of your STM32G0B1 ?

If a rev A is used, a bad option byte programming can lock the device (see errata ES0548: 2.2.9 Device lock upon mismatch of option bytes).

A bad option byte programming could occur if a reset is asserted or glitch on VDD occur during programming phase. 

Best regards,

Simon

[YDann.7]

If I understand right the device marking, it's a revision A.

I'm understand the possibility to lock the device if something wrong.

But I used the STM32CubeProgrammer to change the options bytes value and the MCU is lock so it's really strange.

[Simon.T]

Yes by looking your picture, I confirm that your STM32G0B1 is rev A. To be safe for the next trials I would recommend to use rev Z.

However, using STM32CubeProgrammer to program the option byte values won't prevent you against bad programming when an unwanted glitch on VDD or Reset appears. For example it can be due to low battery voltage, bad debug/reset wire connection ... 

Programming and modifying the option byte is a sensitive sequence a stable environment is required to avoid any further issue