Skip to main content
H
Hank Wang
Associate
August 13, 2026
Question

STM32H523: Device stuck after using NUCLEO-H533RE provisioning project – DA reports success but cannot regain debug access

  • August 13, 2026
  • 1 reply
  • 37 views

Hello ST Community,

I am facing a critical issue while configuring OEMiRoT on an STM32H523 device. I used the official provisioning project from the NUCLEO-H533RE example in STM32Cube_FW_H5_V1.7.0 (since there is no dedicated H523 example). I need help recovering the device.

Background:

  1. I‘ve modified the <DoEncryption> value to 0 according to ‘How to create ROT examples for STM32H5’.

  2. I ran the provisioning project (from the NUCLEO-H533RE example) to configure OEMiRoT on the target STM32H523 device.

  3. During provisioning, the configuration failed and the product state became Provisioned.

  4. After that, the device could no longer be connected via ST-LINK SWD. DA also failed. Then I regenerated a new Key file to confirm if there was any problem during the configuration process.

  5. I still have the private key file key_1_root.pem . But the public key file key_1_root_pub.pem and certificate file cert_root.cert have been overwritten. So I tried the method provided by the AI assistant to generate a public key using OpenSSL, and used this public and private keys to regenerate the certificate file.

    Current situation:

    When I try Debug Authentication (DA) now with STM32CubeProgrammer, the discovery phase shows the following:

    discovery: target ID: 0x478discovery: SoC ID: 0x00000000_39323639_31355117_0028002Adiscovery: SDA version: 1.2.0discovery: vendor ID: STMicroelectronicsdiscovery: PSA lifecycle: ST_LIFECYCLE_IROT_PROVISIONEDdiscovery: PSA verification version: 1.0discovery: Token Formats: 0x00000200discovery: Certificate Formats: 0x00000201discovery: Crypto system: Ecdsa-P256 SHA256discovery: ST provisioning integrity status: 0xEAEAEAEAdiscovery: ST provisioning integrity status message: VALIDdiscovery: Allowed with authorization: Full Regressiondiscovery: Allowed with authorization: To TZ Regressiondiscovery: Allowed with authorization: Level 3 Intrusive Debugdiscovery: Allowed with authorization: Level 2 Intrusive Debugdiscovery: Allowed with authorization: Level 1 Intrusive Debugdiscovery: Allowed with authorization: Level 3 Intrusive Non Secure Debugdiscovery: Allowed with authorization: Level 2 Intrusive Non Secure Debugdiscovery: Allowed with authorization: Level 1 Intrusive Non Secure Debug

    So the DA configuration now appears valid, and the device is in ST_LIFECYCLE_IROT_PROVISIONED with Full Regression permission.

    However, during the authentication step, the CubeProgrammer displays ‘Error:Debug Authentication Failed’. But when I choosed cert_root.cert file, I get this:

  6. [70%] signing tokenSDMAuthenticate : client : Error parsing trust chain (C:\Users\WL\STM32Cube\Repository\STM32Cube_FW_H5_V1.7.0\Projects\NUCLEO-H533RE\ROT_Provisioning\DA\Certificates\cert_root.cert)Debug Authentication SuccessDisconnected from device.Error: Unable to get core IDError: Unable to connect to access port 1! If you are trying to connect to a device with TrustZone enabled, please try to connect using hot plug mode. If you are trying to connect to a device that supports authentication using certificate or password, please use them to open your device.

    It seems that the tool reports Debug Authentication Success, but then it still cannot read the core ID or connect to access port 1.

    What I have tried:

  7. Used STM32CubeProgrammer with ST-LINK SWD.

  8. Checked the NRST connection: MCU NRST is connected to ST-LINK NRST (not TRST), as expected on the NUCLEO board.

Questions:

  1. How can I perform a Full Regression to bring the device back to Open or at least to a state where I can reconnect and re-provision it?

  2. Why does the tool say “Error parsing trust chain (cert_root.cert)” but then still report “Debug Authentication Success”? Is the authentication actually successful?

  3. After DA authentication, why do I still get “Unable to get core ID” and “Unable to connect to access port 1”? What is the correct sequence to regain debug access?

  4. Should I use the system bootloader (UART/USB) instead of ST-LINK SWD for DA on a device in this state? If so, what are the exact steps?

  5. Is the device recoverable with the private key key_1_root.pem? If yes, what is the correct procedure?

  6. Any help would be greatly appreciated. I can provide more logs or details if needed.

    Thank you.

     

1 reply

H
Hank WangAuthor
Associate
August 14, 2026

Good news,

my device has fully recovered after passing DA certification.


When generating a private key through TrustedPacketCreator, an automatic backup of the old private key will be made in the directory, with a name similar to key_1_root.pem_12.08.2026_16_09_05.bak. If this backup still exists, it will not matter even if the public key and certificate are lost or overwritten. The specific method is as follows:


1. In the DA/Keys directory, copy a copy of key_1_root.pem_12.08.2026_16_09_05.bak, and then change the extension of this copied file to .pem format by removing the part after .pem in the name.
2. Use the openssl tool to generate the corresponding unique public key by executing 'openssl ec -in key_1_root.pem -pubout -out key_1_root_pub.pem'. On Windows systems, you can use the Git Bash tool, switch to the current directory, and execute the command.
3. Utilize the TrustedPacketCreator tool, navigate to the DA, Certificate Generation page, select the paths corresponding to the private and public keys, and then choose "generate certificate" in the lower right corner to regenerate the certificate.
4. Then, DA regression can be performed through CubeProgrammer.

    Terms & ConditionsAccessibility statement