[STM32G051] Totally Brick after incorrect option byte change behavior.

[warningyukihyo]

Hello.

I'm using the TSSOP-20 package STM32G051.

After attempting to write some optional bytes, the situation is completely ruined. no longer able connect debugger, Erasing flash, and changing optional bytes.

1. My custom board is configured as follows and worked well without any problems before.

2. Working with STM32CubeProgrammer 2.16.0 and ST-LINK V3, and SWD connection.

2-1. Cannot connect with "Normal", "Under reset", "Power down" Mode. will output the following message and fail:

07:00:24 : UR connection mode is defined with the HWrst reset mode
07:00:26 : ST-LINK SN : ***
07:00:26 : ST-LINK FW : V3J13M4B5S1
07:00:26 : Board : STLINK-V3SET
07:00:26 : Voltage : 0.00V
07:00:26 : Error: ST-LINK error (DEV_TARGET_HELD_UNDER_RESET)

2-2. Can connect only with "hot plug" mode, but all return data is '0'. (Memory view, Option bytes, etc.)

If try Erase Full chip with "hot plug" mode, will output the following message and fail:

04:50:09 : MASS ERASE ...
04:50:11 : Error: Mass erase operation failed.Please verify flash protection

2-3. If attempt to change the optional byte setting with "hot plug" mode, will output the following message and indefinitely waiting.

04:52:52 : Option byte command : -ob RDP=170
04:52:52 : PROGRAMMING OPTION BYTES AREA ...
04:52:52 : Bank : 0x00
04:52:52 : Address : 0x40022020
04:52:52 : Size : 32 Bytes

ST-Link V3's activity LED blinks red/green quickly, so it appears to be continuing to attempt to exchange data.

3. On the RESET pin, 0V is measured. After connecting the external strong pull-up resistor and forcing it pull up and I tried the above process again. but still not working. (returned DEV_TARGET_HELD_UNDER_RESET)

4. I tried using with old 'STM32 ST-Link Tool'. A connection attempt is possible, but the program stops working (main window is not responding. (ST-Link V3's activity LED blinks red/green quickly too.)

It seems that the option byte is contaminated and the wrong function is running. (like Hardware IWDG option, etc.)

but Unfortunately, in the TSSOP-20 package, the BOOT0 pin is already in used by SWD.

Is there anything else I can try? thank you in advance for your support.

[warningyukihyo]

the detailed log of the 2-3 'change the optional byte setting with "hot plug" mode' conditions are as follows:

08:35:03:489 : Option byte command : -ob RDP=170 IWDG_SW=1 WWDG_SW=1 nRST_SHDW=1 nRST_STDBY=1 nRST_STOP=1 IWDG_STOP=1 IWDG_STDBY=1 RAM_PARITY_CHECK=1 nBOOT_SEL=1 nBOOT1=1 nBOOT0=1 NRST_MODE=3 IRHEN=0
08:35:03:493 : PROGRAMMING OPTION BYTES AREA ...
08:35:03:493 : Warning: Option Byte: IRHEN, value: 0x0, was not modified.
08:35:03:493 : Bank : 0x00
08:35:03:493 : Address : 0x40022020
08:35:03:493 : Size : 32 Bytes
08:35:03:494 : OB buffer: aae04f1f00000000000000000000000000000000000000000000000000000000
08:35:03:494 : Buffer program...
08:35:03:499 : halt ap 0
08:35:03:499 : w ap 0 reg 15 PC (0x20000000)
08:35:03:499 : w ap 0 reg 17 MSP (0x20000500)
08:35:03:500 : w ap 0 reg 16 xPSR (0x01000000)
08:35:03:500 : w ap 0 @0x20000B80 : 0x00000200 bytes, Data 0x00000000...
08:35:03:500 : w ap 0 @0x20000000 : 0x00000004 bytes, Data 0x0000BE00...
08:35:03:508 : w ap 0 @0x20000004 : 0x00000754 bytes, Data 0x483EB580...
08:35:03:508 : w ap 0 @0x20000B80 : 0x00000020 bytes, Data 0x1F4FE0AA...
08:35:03:508 : Loader write option bytes...
08:35:03:508 : Init flashloader...
08:35:03:508 : halt ap 0
08:35:03:508 : halt ap 0
08:35:05:000 : w ap 0 reg 0 R0 0x00000001
08:35:05:000 : WriteOB function terminated with connection error due to OB_Launch

then, the STM32CubeProg begins to wait indefinitely.

[Andreas Bolsch]

"... attempting to write some optional bytes." is rather vague. Apparently some PCROP and WRP area settings had been touched. Probably the only way back is reset WRP areas to default (see "ST production value" in RM), set PCROP_RDP bit and do a RDP regression (i.e. increase RDP level to 1, then decrease to 0) and *AT THE SAME TIME* revert PCROP area settings to defaults (again "ST production value").

[warningyukihyo]

Thank you for your answer.

---

@Andreas Bolsch wrote:

"... attempting to write some optional bytes." is rather vague. Apparently some PCROP and WRP area settings had been touched. Probably the only way back is reset WRP areas to default (see "ST production value" in RM), set PCROP_RDP bit and do a RDP regression (i.e. increase RDP level to 1, then decrease to 0) and *AT THE SAME TIME* revert PCROP area settings to defaults (again "ST production value").

---

I agree with this, I was able to read FLASH register using the STM32CubeProgrammer. the FLASH_OPTR data reports 0x00000000. I think the enabled hardware watchdog is triggering a unwanted reset and RDP is set in level 2 (Read protection) mode. my chip is refusing almost any actions including download new firmware, MASS ERASE and CHANGE RDP/PCROP.

Let me simple explain the situation I wanted:

1. I wanted to Enable SRAM Parity by FLASH Option bytes. (I'll call it OB from now on.)
2. I already had an verified OB setup HAL code snippet for STM32L431. that works well for the same purpose and I took this as it is. It's just that the pre-defined name is a different, so I modified it to fit it.

Here's the my code for STM32G051:

// Predefined Option Bytes. just Enable SRAM Parity check
const uint32_t OptByteUserType = (uint32_t)(OB_USER_RAM_PARITY_CHECK);
const uint32_t OptByteUserCfg = (uint32_t)(OB_SRAM_PARITY_ENABLE);

FLASH_OBProgramInitTypeDef FLASHOptByteProgInitStruct = {NULL};

// Reads the current option byte.
HAL_FLASHEx_OBGetConfig(&FLASHOptByteProgInitStruct);
// Make sure the feature is turned on; if not, enter setup mode.
if ((FLASHOptByteProgInitStruct.USERConfig & OptByteUserCfg) != OptByteUserCfg)
{
	// Set parameters
	FLASHOptByteProgInitStruct.OptionType = OPTIONBYTE_USER;
	FLASHOptByteProgInitStruct.USERType = OptByteUserType;
	FLASHOptByteProgInitStruct.USERConfig = OptByteUserCfg;

	// Prepare to write the OB.
	HAL_FLASH_Unlock();
	HAL_FLASH_OB_Unlock();
	// Write OB.
	HAL_FLASHEx_OBProgram(&FLASHOptByteProgInitStruct);
	// Triggers the load of option bytes into option register. If it was run correctly, it will trigger a System reset.
	HAL_FLASH_OB_Launch();

	// ...did it run this far without reset? it's not good, but first LOCK THE FLASH AGAIN.
	HAL_FLASH_OB_Lock();
	HAL_FLASH_Lock();

	// Do something for Error handling.
	// ...
}

...and this code runs, and my STM32G051 is gone.

I don't know why the HAL code snippet did that. Still not good, also I can't even replace chips now. It's sad. :'(

[warningyukihyo · Accepted solution]

In conclusion, I replace the chip and decided to use G031, not G051. package is the same TSSOP-20.

I was experiment with the possibility of recovery when the FLASH OB value is corrupted (filled all by 0) for G031 and G051. G051 was unable to escape reset held and rejects all flash memory-related actions, including write OB and RDP. No response to BOOT0 pin status too. but G031 was able to mass erase and reuse by rewrite the OB and RDP value.