Flash bricked after RDP changes on several STM32G0

rcard · ‎2021-02-10

Currently developing a product to update the firmware of a product through SWD, i encounter an issue with the flash of the target (STM32G070RB).

After multiple changes in the RPD (from 0->1 & 1->0) the flash of the MCU can't be erased.

Some word will not erase to 0xFFFFFFFF, but instead will be at 0xFFFF0080.

Once it's in that state, changing the RDP to trigger a mass erase will not fix the flash. The STLink is unable to mass erase or page erase the chip, and also unable to program anything to the chip.

Initially i though that my programmer was the issue of the flash error of the target. But when it happens it was when changing the RDP from 1 to 0 with the STLink. I was not sure of that on the first occurrence of the issue. But today it happened again, while not using my own programmer at all.

So i am now sure that it happen after changing the RDP from 1 to 0 using the STLinkV3.

Does anyone already encounter this issue?

Imen.D · ‎2021-02-11

Hello @rcard ,

Have you upgraded the ST-link firmware? Is this behavior random or systematic ?

Have you checked if this behavior has occurred with other boards?

>> Once it's in that state, changing the RDP to trigger a mass erase will not fix the flash.

According to the refetence manual : The change from Level 1 to Level 0 triggers full mass erase of the Main Flash memory.

Do you have this issue when using latest release of STM32Cubeprogrammer?

From you post, I understand that the reset doesn't get driven and the RDP is still set to RDP1. Meaning the switch to RDP0 level didn't happen.

Maybe you can try with CubeProgrammer to modify RDP through software: just initialize the software and program the option byte, then excecute OBL_LAUNCH (generates a reset), without debug mode, as this is not possible in mode debug.

The option byte loader reset is generated when the OBL_LAUNCH bit is set in the FLASH_CR register (to validate the protection level change). This bit is used to launch the option byte loading by software. Then, you can check the RDP level with STM32Cubeprogrammer.

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

rcard · ‎2021-02-11

Hello @Imen DAHMEN , thanks you for your reply.

The STLink V3 i'm using is currently in the V3.J7.M2.B4.S1 version. The issue happened with two MCU, both are STM32G070RBT6 on a custom boards (not the same board in the two occurrences of the issue).

I'm not using the STM32CubeProgrammer, but the STLink utility instead.

When the bug occured the RDP change worked as expected changing from 1 to 0. But the mass erased triggered by the RDP change failed to erase the flash properly. Instead of that the whole flash is a set to 0xFFFF0080FFFFFFFF.

When the MCU is in this state i can still change the RDP using the STLinkUtility. From RDP0 to RDP1 and RDP1 to RDP0, without issue, except for the flash.

When trying any type of erase using the STLinkUtility i encounter an error. Same when trying to program the MCU.

I can not use the STM32CubeProgrammer because the faulty MCU is currently not soldered on the board. I will re-solder it to test with the CubeProgrammer.

Romain

rcard · ‎2021-02-11

Ok so after soldering the last faulty STM32G070RBT6 to a NucleoG070, and using STM32CubeProgrammer i obtained interesting result:

-The flash read initially returned the same values i had with the STLinkUtility (0xFFFF0080FFFFFFFF)

-Chip Mass Erase returned an error

-RDP changes are working, BUT after few changes the flash changed value, as you can see in the next screenshot:

Nothing else changed. The flash is still stuck in this state. Can not program/erase the chip.

Luk35 · ‎2021-12-10

We have similar issue with STM32G030 chips after changing RDP from 1 to 0. Flash after mass earse has stucked at 0xFFFF0020. Did someone solved this issue?

We have tried with J-Link, ST-Link... Result is identical: can program MCU. Bricked.

MMcAl.1 · ‎2022-05-27

The same issue happens to me with a G030. After removing RDP protection (from 1 to 0) it bricks the mcu with 0xFFFF0040. Tried also latest STM32 cube programmer.

This is a huge problem!

Luk35 · ‎2022-05-27

If disabling RDP makes 0xFFFF0040 then

Make PCROP_RDP checked, enable RDP level 1
Program option bytes.
Disable RDP.
MCU should be erased to 0xFFFFFFFF

I noticed that checking PCROP_RDP in MCUs that erases properly, makes problem with connecting. So I am performing above procedure only to devices that erases to 0xFFFF0040.

MMcAl.1 · ‎2022-06-13

Thank you, it works!

kambersimsek · ‎2023-10-14

thanks this is work for STM32g070cb products 🙂 have a nice day.