STM32U0: question about RDP regression

RAltm · ‎2025-08-13

Hello,

I'm not sure if I understand the RDP regression mechanism described on STM32U0 reference manual (RM0503 rev4) correctly. My general understanding is that it's possible to go from RDP2 => RDP1 => RDP0 if the OEM keys are set - if they are not set (all 0's or all 1's) the effect of RDP2 is the same as on devices without RDP regression feature, so the debug port is fully closed and can't be opened anymore.

My confusion comes from the following descriptions of the manual:

RDP level 2 description on page 79 states that the CPU debug port is disabled under reset.
The same description states:
Once in level 2, it is no more possible to modify the read protection level.
Note 1. on page 80:
When the protection level 2 is active, the Debug port, the boot from RAM and the boot from system memory are disabled.
Contrarily, OEM RDP lock mechanism description for OEM 1/2 on pages 81 & 82 states that it's possible to go from RDP2/1 to RDP0/1 and states that the keys must be written to the DBGMCU_DBG_AUTH_HOST register by the debug interface under reset.

The DBG debug block diagram on page 1246:

To me it looks like the used terms are not detailled enough or mixed. And the statement from #2 above is outdated.

So, just to be sure that I understand it correctly: The part marked red corresponds to the CPU debug port from #1 & #3 and is disabled on RDP2, the green one is the debug interface from #4 above and still (always?) enabled, therefore it allows the regression by the OEM keys? Also, the green one is not available on devices without regression feature, right?

Would be nice if someone can confirm my interpretation of the manual. Additionally, I've the following questions:

As long as the OEM keys are set it's always possible to "rescue" a device?
There's no way to fully disable the SWD interface? The only way to fully disable it is to not program the OEM keys and additionally disable the SWD by software within the application, right?
What's the purpose of the OEM 1 key mechanism? If a RDP2 device is moved to RDP1 by OEM 2 key it should be possible to get to RDP0 without the OEM 1 key, at least according to the documentation. Or does the regression mechanism enforce usage of the OEM 1 key to get from RDP1 to RDP0?

Regards

Jocelyn RICARD · ‎2025-08-14

Hello @RAltm

As long as the OEM keys are set it's always possible to "rescue" a device?

As long as you have the key, yes you can reopen the device

There's no way to fully disable the SWD interface? The only way to fully disable it is to not program the OEM keys and additionally disable the SWD by software within the application, right?

The DBG_SWEN is not really useful when using RDP2 because debug interface is disabled anyway.

The only thing you can do in RDP2 is to shift bits on the debug interface in reset. The debug IP of the code is disabled.

What's the purpose of the OEM 1 key mechanism? If a RDP2 device is moved to RDP1 by OEM 2 key it should be possible to get to RDP0 without the OEM 1 key, at least according to the documentation. Or does the regression mechanism enforce usage of the OEM 1 key to get from RDP1 to RDP0?

If you don't provision OEM1 key you can do the regression from RDP1 to RDP0 as usual.

As soon as you provision a OEM1 key, you must use it to regress from RDP1 to RDP0. This can be used as a protection.

Best regards

Jocelyn

RAltm · ‎2025-08-14

Hello @Jocelyn RICARD

okay, so I really need to differentiate the terms - that's why I was confused from the statements of the documentation:

@Jocelyn RICARD wrote:
The DBG_SWEN is not really useful when using RDP2 because debug interface is disabled anyway.
The only thing you can do in RDP2 is to shift bits on the debug interface in reset. The debug IP of the code is disabled.

So, debug interface disabled simply means it's not possible to debug. But the SWD interface is still open, allowing to use the OEM keys to re-open the debug interface, right?

@Jocelyn RICARD wrote:
If you don't provision OEM1 key you can do the regression from RDP1 to RDP0 as usual.
As soon as you provision a OEM1 key, you must use it to regress from RDP1 to RDP0. This can be used as a protection.

That means that lowering the RDP level is always bound to the OEM keys? In the past, I only worked with devices without the regression feature. On those devices RDP2 couldn't be changed and RDP1 to RDP0 was always possible. That's why I thought the OEM1 key is optional, but it seems it's not.

Regards