cancel
Showing results for 
Search instead for 
Did you mean: 

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

CLi P.1
Associate

 

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();
}

 

CLiP1_0-1722916168884.png

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).

CLiP1_1-1722920855219.pngCLiP1_2-1722920875617.png

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?

CLiP1_3-1722921283774.pngCLiP1_4-1722921369936.png

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

CLiP1_5-1722921583120.png

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!

 

 

0 REPLIES 0