STM32G030K8 when set RDP to level1 has chance cause the MCU to be brick

[CLi P.1]

Hi,

I want to add a function in the code to update the option bytes and set the read protection to level 1. However, this version sometimes bricks the MCU (STM32G030K8) after flashing, making it unable to connect with the J-Link.

Q1: Why am I unable to reconnect to the J-Link? Shouldn't it be possible to connect if it enters the system flash (as long as the MCU is not physically damaged, it should theoretically be reprogrammable)?

Q2: Is there any way to recover the MCU from the bricked state?

Q3: Is this issue caused by a flaw in my code, or is it a problem with the MCU itself?

===========

Here are my reproduce steps:

1. I added optionByteInit() during the initialization phase in the code.
2. Built for Debug and generated a Hex file.
3. Flashed it using J-Link SWD (using STM32CubeProgrammer).
4. After successful flashing, I powered off the MCU and then tried to connect using STM32CubeProgrammer.
5. Failed to connect.

void optionByteInit(void){
	FLASH_OBProgramInitTypeDef pOBInit;

	/* Read the original Option bytes setting */
	HAL_FLASHEx_OBGetConfig(&pOBInit);

	/* Read protection setting */
	/* Unlock Flash */
	HAL_FLASH_Unlock();
	HAL_FLASH_OB_Unlock();

	/* Option byte setting*/
	pOBInit.OptionType = OPTIONBYTE_RDP;
	pOBInit.RDPLevel = OB_RDP_LEVEL_1;
	HAL_FLASHEx_OBProgram(&pOBInit);

	/* Enable the new option bytes setting*/
	HAL_FLASH_OB_Launch();

	/* Lock Flash */
	HAL_FLASH_OB_Lock();
	HAL_FLASH_Lock();
}

After it bricked, I tested with a new MCU and flashed the same Hex file. It worked normally. (STM32CubeProgrammer showed flash memory values as AAAA....AAA, and the Option byte page showed Read protection set to 0xBB).

I have checked the following:

1. The MCU is not physically damaged (no short circuits, overvoltage, overcurrent, etc.).
2. I tried pulling Boot0 (PA14) high to enter System memory, but it still failed.

Note: I found that the default option byte setting does not use Boot0 but nBoot0, meaning it might not be possible to enter System memory using nBoot0?

This is the schematic of the MCU I used for testing.

Here are some links to similar cases I found in the community:

1. Link 1
2. Link 2

If there is anything you need to add or something is unclear, please tell me, thank you!

[TDK · Accepted solution]

> Q1: Why am I unable to reconnect to the J-Link? Shouldn't it be possible to connect if it enters the system flash (as long as the MCU is not physically damaged, it should theoretically be reprogrammable)?

> Q2: Is there any way to recover the MCU from the bricked state?

Since nBOOTSEL = nBOOT0 = 1, the chip will always boot to user flash and ignores the state of the BOOT0 pin.

Connecting NRST to the debugger would allow you to connect under reset, which would be another method to recover the chip.

> Q3: Is this issue caused by a flaw in my code, or is it a problem with the MCU itself?

You should avoid writing code which ALWAYS sets the option bytes. Rather, write code that reads the current values and changes them only if they are not what you want. Always writing option bytes at the start of the program may prevent SWD from working, just as always resetting the chip or entering low power modes or re-assigning SWD pins will prevent communication.

HAL_FLASH_OB_Launch causes a system reset, so the code you've written puts the chip in an infinite reset loop.