STM32H755XIH6 PCROP Recovery - Almost Entire Flash Protected, Cannot Modify Option Bytes

[Engineer29]

I accidentally configured PCROP protection on my STM32H755XIH6 that has effectively locked me out of almost the entire flash memory, and I'm unable to recover using standard methods.

Current Situation:

• Device: STM32H755XIH6 (2MB dual-bank flash: Bank1=1MB, Bank2=1MB)
• PCROP Settings:
  • Bank 1: PROT_AREA_START1=0x2 (0x08000200) to PROT_AREA_END1=0xFFF (0x080FFFFF)
  • Bank 2: PROT_AREA_START2=0x2 (0x08100200) to PROT_AREA_END2=0x81FFFFF)
• Available Space: Only 512 bytes per bank (0x08000000-0x080001FF, 0x08100000-0x081001FF)
• Problem: Almost all of flash is PCROP-protected

I tried the below methods following some other discussion on the forum:

1. STM32CubeProgrammer GUI - option byte modifications fail with "changes can't be applied after OB_LAUNCH" (It connects under reset but I still get changes cant be applied after OB_LAUNCH error)
2. CLI commands to modify PROT_AREA_START/END - all fail with same error
3. RDP level cycling/regression (0xAA → 0xBB → 0xAA) - completes but PCROP settings remain unchanged
4. Mass erase operations - succeed but protected areas remain unwritable

Current Status:

• Can connect via SWD in normal mode
• DMEP1=1, DMEP2=1 is set but seem ineffective

Given that I can only execute code in 1KB total space (512 bytes per bank) and cannot modify the option bytes through any standard method, is there any legitimate recovery procedure for this situation?

I saw in this discussion Solved: PCROP Not disabled after RDP Regression, Option ch... - STMicroelectronics Community that this user had to execute bank mass erase with automatic protection-removal code for it to recover, should I write a bare basic code to get this to run in the 512bytes I have? 

[Bubbles]

Hi @Engineer29,

indeed, to remove the protection the mass erase or the RDP regression must be requested simultaneously with the PCROP removal, otherwise it's not executed. I'm not sure if the tools are capable of modifying both OB in one go, but sure give that another try.

Regarding removal using the user code, you don't really need to squezze the code to 512B, even though it doesn't seem unrealistic at all. You can also configure the project to load the executable to RAM and execute from there.

BR,

J