RDP level is 0xFF after power-down from programmer pins on PCB

[hkoc_poelsan]

Hello,

I am developing with an L4 series MCU.

If there is a program in the MCU and the read protection flag is not active (Level 0), when I load a program that activates the read protection flag (Level 1), there is no problem if I cut the power from the USB port or the programming pins.

But if the MCU's read protection flag is active (Level 1) and I set it Level 1 and load a code that activates the read protection flag (Level 1) in the program again, when I power down by removing the programmer pins and give it again. In that case, the program doesn't start and when I connect with cubeprogrammer, RDP is active and its value is 0xFF instead of 0xBB.

When I examined it a little more, I saw that the PCROP values ​​​​changed when the code did not start. Probably the reason why the code did not start is that PCROP_RDP is active.

But the question is why do I experience this if I power down by removing the programmer pins?

[Frantz LEFRERE]

Hello @hkoc_poelsan ,
if fact Option byte are stored in flash  ( not the user flash but in a dedicated location). To program flash, you need first to erase it.
When you program option byte, first this location will be erased ( so it's content will be 0xFF) then program with the new values.
So in case of power lost or spurious reset during option byte programming, this could drive to have 0xFF for all the option byte. This is why it was states in the reference manual, you should insure about power supply and prevent any reset during optiuoin byte programming.
If you program option byte from embedded software, please insure to program them only when it's needed ( I mean check the current value to decide if the programmation is needed or not).

I hope it clarifies.

Br,

Frantz

[hkoc_poelsan]

Hi Frantz, 

"So in case of power lost or spurious reset during option byte programming"

I am sure that I didn't experience any power loss during the option byte programming, I will explain below how the problem occurred.

I program option byte from embedded software. After uploading the program I check the current value of RDP level. It is all clear.

Suppose that I have installed a program on my device before and the current RDP level is 0xBB. I connect with CubeProgrammer and set the RDP level from 0xBB to 0xAA. Then upload the program again (option bytes are programmed from embedded software). After uploading, if I power down by removing the programming pins for power cycling then I power up again my device doesn't run. I connect with CubeProgrammer and RDP level is 0xFF and PCROP_RDP is set. I never set PCROP_RDP from embedded software.

This happens only if I power down by removing the programming pins. All of them are OK (RDP level is 0xBB, and PCROP_RDP is reset) if I power down by removing the USB port. 

[Frantz LEFRERE]

Hi @hkoc_poelsan,

In the following MOOC, I explain how to setup RDP without power cycle ( not needed in your case):
https://www.youtube.com/watch?v=f7vs0NwZPFo

You have code example how to test and set the option byte. :
https://drive.google.com/drive/folders/1PZP9pm9mHpFM4yk2PaPOQ1gHAbk7ttYU

"This happens only if I power down by removing the programming pins. All of them are OK (RDP level is 0xBB, and PCROP_RDP is reset) if I power down by removing the USB port. "
When you upload via debugging link are you sure you are not launching your firmware  and power down before end of option byte programming ?

"power down by removing the programming pins" -> sorry what does it mean ?
programming pins never power a target...

"power down by removing the USB port" ... Could you clarify how is powered your board ?

Br,

Frantz 

[HuWei]

I also encountered the issue of RDP Level being 0xFF when using STM32F030C8T6.How should I reset it to 0xAA?I consulted with the supplier and they told me that it is currently impossible to restore to 0xAA. Is this really true?