2026-04-11 4:36 AM - last edited on 2026-04-13 6:59 AM by Andrew Neil
Hello STM32 Community,
I am stuck in a critical situation with my STM32H533RE custom board and need help recovering it. I have exhausted all methods I know.
- Hardware Setup:
- MCU: STM32H533RE (custom PCB, not Nucleo)
- ST-LINK: External ST-LINK V2 (Firmware V2J46S7)
- BOOT0: carry out the cia test point
- USB: DP/DM routed to test points (wires soldered for access)
- SWD: SWCLK , SWDIO , NRST (Pin 2) connected to programming header
- TrustZone Configuration
- Configured Secure and Non-Secure world using STM32CubeMX
- Secure peripherals: SPI1, SPI3, UART4, ICache, DCache
- Flash watermarks configured for secure/non-secure regions
- What Happened (Step by Step)
1. Device was originally in **Open state (0xED)** — everything worked fine
2. I could connect via SWD in Normal mode and read all memory including secure regions
3. I attempted to transition Product State from **Open (0xED) → TZ-Closed (0xC6)** via STM32CubeProgrammer Option Bytes tab
4. The device transitioned to **Provisioning (0x17)** and stopped there (the two-step transition Open→Provisioning→TZ-Closed did not complete)
5. After this, Normal SWD connection stopped working
6. I was able to connect using **Hot Plug mode, Access Port 1, SWD** and confirmed: - Product State = 0x17 (Provisioning) - Device detected as STM32H533/523, 512KB, Cortex-M33 ## Attempted Recovery — All Failed
Attempt 1: OB regression via GUI (Hot Plug, AP1) Changed PRODUCT_STATE from 17 → ED (Open) in Option Bytes tab and clicked Apply.
Error: Expected value for Option Byte "PRODUCT_STATE": 0xED, found: 0x17 Error: Option Byte Programming failed Or modified by application after OB_LAUNCH
Attempt 2: Forward transition 17 → C6
Attempted to complete the transition by setting PRODUCT_STATE to 0xC6.
Result: Connection lost after this attempt. Device no longer connects.
Attempt 3: Mass Erase
- Tried mass erase via ST-M32CubeProgrammer.
Error: Mass erase operation failed. Please verify flash protection
2026-04-11 4:55 AM
You’re dealing with an STM32H533 stuck in Provisioning state (0x17) and now nothing connects, yeah that’s a tough spot honestly. From what it looks like, once TrustZone + product state transition fails mid-way, the device can get kinda locked and normal recovery paths stop working. Usually going back to Open from Provisioning/TZ-Closed isn’t really allowed, ST designed it as one-way for security, so regression often fails. If SWD + DA both not responding, chances are debug access is fully blocked now. Only thing left might be ST internal tools or support case with STMicroelectronics, they sometimes have recovery methods not public, otherwise chip might be permanently locked.
2026-04-11 5:44 AM
Thank you for your time and suggestion.
Yes, that’s why I posted, if anyone can help me.
2026-04-11 5:57 AM
You can’t switch it back to Open directly. You must complete the provisioning process.
2026-04-11 6:00 AM
At the moment, I am unable to connect to the STM device using STM32CubeProgrammer.
Could you please guide me on the steps to follow and what needs to be set up?
2026-04-11 7:22 AM
This usually means the STM32H533RE is stuck in a secure provisioning mode—like a batsman completely “locked on crease” with no shots available :grinning_face_with_sweat:—so SWD, DFU, and UART all get blocked. It often happens due to TrustZone or option byte misconfiguration. You can try recovering using STM32CubeProgrammer with “Hot Plug” and attempt a full chip erase, or force BOOT0 to enter system bootloader mode and retry. If that still doesn’t work, then it’s like losing all wickets—access may be permanently restricted unless regression (RDP downgrade) is allowed, so double-check security settings carefully.
2026-04-12 5:10 AM
I can’t connect to the STM device using STM32CubeProgrammer. What steps should I follow and what needs to be set up?