STM32H7 unaccessible after secure area configuration.

[VPanc.1]

I was trying out various security protection mechanisms on my NUCLEO-H753ZI and after configuring the secure user memory area, I can no more access my STM32 via ST-LINK.

I haven't configured the RDP, it was at L0. No other protections were set.

I think the MCU needs to be maas-erased, but how do I perform that without the MCU getting detected by ST-LINK.

Does anyone know how to get my MCU detected by the ST-LINK?

[Tesla DeLorean]

Perhaps try via the serial port and ROM based system loader which starts when resets with BOOT0=HIGH​

[VPanc.1]

This doesn't seem to work, I think it doesn't execute the system bootloader while booting from secure mode.

[Tesla DeLorean]

It's generally advisable to add your own back-doors when playing with security / locking methods, so at the very least you can inspect and understand what's happening internally when the debug connection has been rendered in-operative. Being able to load / execute arbitrary code from RAM being a particularly powerful method.

Expect perhaps to brick "secure" several devices in your pursuit of understanding. Usually better to do with socketed IC fixtures, or have someone on-hand with good soldering/rework skills.

[Pavel A.]

This is intended. Active "secure area" disables debugger connection to the MCU, similar to RDP level 2,

and it also disables the system bootloader.

Debugger can connect only after exit from the "secure area" to user code.

Try to connect under reset with CubeProgrammer and do mass erase or so called "regression" (set RDP level 1, then reset and change RDP to 0).

If CubeProgrammer cannot connect even under reset - then unfortunately the MCU is bricked.

[VPanc.1]

ST-Link didn't "connect under reset" with CubeProgrammer.

[Pavel A.]

Then looks like it's bricked.

(please someone correct, if my understanding is wrong)

The "secure area" is intended to create a small "root of trust" bootloader with single entry point, while allowing debugging the main application - without completely going to RDP level 2. The bootloader should exit to the application code ASAP (otherwise you could use RDP1/2 as well).

​It is also a sort of "proprietary execute-only area" - but easier for developer, as it does not require the special execute-only compiler mode.

​

Upon reset, if the secure area is active, it does its magic and blocks debugger connection (*)

To start debugging the application, the debugger should connect in hot-plug mode and break into the app code - otherwise a system reset will activate the "secure area" again.

​Therefore, if the bootloader gets stuck in the secure area and fails to jump out, the MCU is bricked.

​

If the debugger/programmer can connect (break into the app or somehow else), you can inject RAM code to do RDP1->RDP0 regression, which erases the secure area and/or deactivates it. Or change the option bytes directly by the CubeProgrammer.

​

(*) this IMHO is a major bug. The secure area alone (without RDP2) should allow easy recovery so debugger connection under reset should be allowed to change the option bytes.