Stuck in Provisioning State (0x17) - Cannot connect via SWD, USB DFU, or UART

[Dhaval_Shiroya]

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

Attempt 4: Under Reset mode

- Tried connecting with Mode = Under Reset, various Access Ports (0 and 1).

Result: Cannot connect.

 

Attempt 5: BOOT0 = HIGH (System Bootloader)
- Connected BOOT0  to VDD (3.3V) via jumper
- Pressed RESET / power cycled the board
- SWD: Tried all combinations (Normal/HotPlug/UnderReset × AP0/AP1 × Freq 100/4000) : None connect
- USB DFU: Connected USB DP/DM to host PC : Windows does not detect any new USB device. No "STM32 BOOTLOADER" or "DFU device" appears in Device Manager
- UART: Connected TTL UART adapter to USART1 (PA9/PA10) : CubeProgrammer UART mode does not connect

 

Attempt 6: Different ST-LINK
- Used a completely different ST-LINK probe.
Result: Same errors. Cannot connect.

Attempt 7: Debug Authentication (DA)
- In Secure Programming section, When click on discover button
Error: Failed to communicate with target

Current State:
- Product State:*0x17 (Provisioning) - or possibly changed during failed attempts
- SWD: Cannot connect in ANY mode (Normal, Hot Plug, Under Reset) with ANY Access Port (0 or 1)
- USB DFU: Not detected by host PC even with BOOT0 confirmed HIGH
- UART Bootloader: Not responsive
- ST-LINK: Detected by Windows, shows serial number and voltage (3.29V) in CubeProgrammer
- Board: Powered correctly (3.3V confirmed)
Error: Cannot connect to access port 1 (or 0)! If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode. If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it.


Questions:

1. How do I recover an STM32H533 stuck in Provisioning state (0x17) when SWD, USB DFU, and UART are all not connecting?

2. Could the device have transitioned to a state beyond Provisioning (0x17) during the failed OB_LAUNCH attempts? How can I determine the actual current product state without being able to connect?

3. Is there an ST tool or procedure specifically designed for recovering devices stuck in Provisioning state?
4. Can we goes back to "open mode" from any other mode like provisioning, TZ-closed? or is it reversible?

Any help would be greatly appreciated. This is a custom board for a production project and I need to recover this device if possible.

 

Thank you.

[eva_402]

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.

[Dhaval_Shiroya]

Thank you for your time and suggestion.
Yes, that’s why I posted, if anyone can help me.

[sarahlauren0471]

You can’t switch it back to Open directly. You must complete the provisioning process.

[Dhaval_Shiroya]

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?

[sarahlauren0471]

I can’t connect to the STM device using STM32CubeProgrammer. What steps should I follow and what needs to be set up?

[Alexandercharli]

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.