How to regress STM32U585-based device from RDP 2 to 0 without completely removing power from the device?

[TKoja.2]

Hi,

I have a custom board built around an STM32U585AII6 that utilizes RDP level 2 to prevent debug access. In the firmware I provided keys to allow for regression from level 2 back to level 0 and have been able to do this regression through the Cube Programmer successfully on many occasions, but only when I completely remove power from the device in between the various steps of the process. A successful regression typically follows the sequence below:

1. Successfully Apply RDP Level 2 Password
2. Disconnect Device from power source
3. Reconnect power and successfully connect to the Cube Programmer
4. Successfully Apply RDP Level 1 Password
5. Disconnect Device from power source
6. Reconnect power and successfully connect to the Cube Programmer
7. Set RDP option bytes to Level (0xAA)

Is it a requirement to completely remove power from the device or is it possible to perform RDP regressions while keeping the device power?

[WojtekP1]

In documentation it's said that reset should be enough. As you already observed it's not.

But there is a workaround:

• set up RTC alarm one second from now and enable alarm interrupt.
• go to deep sleep - standby mode
• after one second it will wake up from standby mode which means reset. And it will start properly with RDP updated.

I've got that info from polish STM32 distributor after consulting ST. Works at least in STM32L0 and L4. Not tested on newer models.

It was even more needed for me than in your case - our product included 5F supercap as energy storage. The only way to turn off power on production board would be to discharge that supercap - quite a bit complex to do

[TKoja.2]

Hi @Community member​,

Thanks for such a quick response!

Just to clarify, were you using this workaround to put the device into RDP Level 2?

I'm having trouble getting a device currently in RDP Level 2 back to Level 0, which may only be a feature for the STM32U5 series.

[WojtekP1]

No. From 0 to 1 or from 0 to 2 after better testing - for my bootloader which then allowed encrypted firmware to be uploaded. bootloader itself could too be upgraded - by loading special "firmware" that just replaced bootloader after start and cleared itself then.

It wasn't meant to be downgraded and never been.

I'm 99% sure it will work same. This "feature" - hanging after reset if RDP is changed by program itself - is AFAIK common to all of series. Maybe they changed something in U series.

I never used U series. F, L, G and C.

[Piranha]

The MCU locks shortly after setting the RDP protection, if the debugger is still connected. Going into Standby or Shutdown mode and disconnecting the debugger is the typical way to solve it. The wake-up source doesn't matter - it can be a wake-up pin, RTC or anything that works in those modes.

[Pavel A.]

Can it be a watchdog reset, without standby/shutdown?