Accidental MCU/Flash write lock up: My misuse or CubeProg bug?

[ZSvet.1]

While programming OptionBytes or FW on STM32WLx5 most of the time is OK.

In CubeProg I have noticed, that on some MCUs, when I get reading of RDP 0xFF or 0,

the next action to program something write related, it could not be done and it's failed.

Statistically it's happening too often, 4 failed of 11devices ....

(I had also one device, that MCU was fresh and it was already in this state..

had RDP already 0xFF - no write action possible)

I can also assure, that I did not programmed any protection at this stage, it's to early.

Is there any workaround to overcome this write lock state?

Have checked the topics in the community, for example this.

But it seems different flow to the same consequence ?

If someone can help me understand this situation?

What I already find out:

• Could it be that MSI clock 48MHz got preserved into bootloader mode?

(Erratum System 2.2.2 explains high frequency problem)

• Could it be difference using the ST-Link v2 or v3?

By no means FW is programming any OB bytes or something related.

This symptom was observed with CubeProg(Linux) v2.12 and v2.13.

I would really appreciate any focus or further information on this topic!

Thanks in advance.

[Sara BEN HADJ YAHYA]

Hello @Community member​ ,

Thanks for your feedback,

If RDP is set to 0xFF or 0xBB or any value other than 0xAA (Level 0: no protection) and 0xCC (Level 2: Chip protection), it means that the MCU is read protected (Level 1). So it won't be possible to program the MCU.

You need to change the RDP level from 1 to 0, to do so you just need to select 0xAA and then click on Apply button to save the changes.

 

I hope this helps!

Sara.

[ZSvet.1]

Dear Sara,

Thanks for clearing things for me.

I think I am aware of the levels and what they mean.

(Special care, while it's irreversible, I know that)

With few MCUs my observation of the RDP value was:

- when exactly FF or simply 0, causing unexpected issues,

or expected?! => to have MCU lock in Level 1 or 2.

(FF and 0 values are not listed in the RDP Combo-box, odd behavior or bug?)

The problem is next, I did NOT program the RDP like select BB or CC,

just wanted to program OB for nBOOT.

(The value of the RDP Combo could be left at FF or 0 as it was preset at CubeProg connect time)

With further tests on fresh MCUs will try to record a video, if I could see the symptom again.

And I believe I could, since it happens few times already.

To put it simple: whenever I see RDP: FF or 0, MCU lock itself into read-protected Level 1 or 2.

Here is my question - why did that happened?

I did not choose 0 or FF or BB or CC, but it lock itself while OB programming.

Perhaps you have more knowledge about this.

Will keep you posted with further experiences.

BR

[Sara BEN HADJ YAHYA · Accepted solution]

Hello @Community member​ ,

You are right the values FF and 0 are not listed in RDP combo box, this is actually a normal behavior and as mentioned in the description of RDP, any value other than 0xAA and 0xC, the MCU is read protected. So FF and 0 means that the MCU is at level 1 and OB programming doesn't impact RDP.

As I mentioned in my previous comment you need to change the RDP to AA to unlock the device.

Sara. 

[ZSvet.1]

Hello Sara,

I have managed to unlock one MCU, but not thru RDP re-programming.

(The writing of AA was not successfull)

With CubeProg v2.13 the Unlock Chip button has more broad support than with v2.12.

Unlock Chip with power-cycle did actually put the MCU into some state

where I could further program RDP/OB and successfully flash FW.

Thanks for your support, I have gained some trust 🙂

Will keep you updated on the further testing/experience.

BR Ziga