2026-03-15 1:25 PM - last edited on 2026-04-21 4:06 AM by Imen.D
I was trying to implement emulated EEPROM and I think I set the EEPROM page area right into the critical option bytes area. Notably, this didn't happen until I added the actual eeprom_emul.c and flash_interface.c files into the cmake configuration, compiled and flashed the program once. This obviously makes a call to "HAL_FLASH_UNLOCK()" so I think it's pretty messed up.
Either way, after this, I could not flash the chip beyond 0x80000050, additionally, it would instantly lock up on boot. I believe my Option Bytes were also grenaded. PCROP_RDP turned itself on, ESE turned itself on and the rest I am unsure of changes. Either way, I managed to turn off RCROP_RDP by setting RDP to 1 and then to 0. After this, flashing the chip, fills every line with the same repeating nonsense bytes. So I think write protection is disabled, but it's still uploading nonsesen. Notably, trying to hit "full chip erase" does not work, and just hangs. Now ESE remains checked. When trying to uncheck it, STM32PRogrammer reports "ESE does not exist".
Is this STM32 fully bricked, or can it be recovered by setting specific optiobn bytes in a specific order?
2026-05-12 2:12 AM
Hello @YamiTheWitch,
You can try the following method to recover it, assuming the device is not permanently bricked:
Use STM32CubeProgrammer to connect with SWD, Under Reset, Hardware reset, and a low speed such as 100 kHz. Then set RDP to Level 1 and apply it, reconnect under reset, and set RDP back to Level 0. This should trigger a mass erase. After a power cycle, reconnect under reset, try a full chip erase, and flash a small known-good image at 0x080000000.
If that works, the chip likely is not bricked — the EEPROM emulation pages were probably placed in the wrong flash region.
Best regards,
Ouadi