cancel
Showing results for 
Search instead for 
Did you mean: 

Wild issue! STM32H7S78 stuck after DA provisioning!

R_1
Associate III

Overview
Debug Authentication Discovery occasionally succeeds in CLOSED state, but Full Regression fails (“Unable to boot on RSS_DA” / “Unable to detect DBGMCU Mailbox”)

Get ready for the stm32 safari!

 

Product / Environment
- Board: Custom based off of STM32H7S78-DK (MB1736)
- MCU: STM32H7S7L8H6H
- Debugger(s) used: STLINK-V3SET
- Tool: STM32CubeProgrammer v2.19.0
- ST-LINK FW: V3J17M10B6S1
- Board setup used during recovery attempts:
- tried altering Boot0 (boot from RSS/system flash)
- tried manual reset
- tried low SWD speed and hardware reset modes

 

Summary of the issue
I was attempting to recover the board after secure configuration experiments. The board was originally reachable over SWD, but after running the **`ROT_Provisioning/DA/provisioning.sh`** flow from the STM32CubeH7RS package, normal SWD access stopped working. The board is now in **CLOSED** state, and **Debug Authentication Discovery** can occasionally succeed if I hit a very narrow timing window at power-up, but any DA action command (including **Full Regression**) fails.
I really would like to get the board back into 'Open' state by running a regression.

The main failures are:
- `Unable to detect DBGMCU Mailbox`
- `No response from the target`
- `The target is unable to boot on RSS_DA or is in OPEN mode`
- even though successful Discovery clearly reports the device as **CLOSED**

For this board family, ST documents that **Discovery** is available in **Provisioning** and **Closed** states, and **Full Regression** is supported on **STM32H7Rx/7Sx**. ST also documents that DA communication uses the device’s **DAP0 / DBGMCU** path, which appears to be exactly where the failure occurs.

 

Exact sequence that led to the issue
1. The board was originally reachable over normal SWD.
2. I ran the official STM32CubeH7RS **DA provisioning** flow from: `Projects/STM32H7S78-DK/ROT_Provisioning/DA`

This H7S78-DK package documents this folder as the official **Debug Authentication** script/package location, including `provisioning`, `discovery`, `ob_programming`, and `regression` scripts.

3. After running **`provisioning.sh`**, normal SWD connect began failing.
4. The board now behaves as though DA is only reachable in a very narrow power-up window.
Much to my dismay, I am unable to execute a regression.

 

Current behavior

1) Normal SWD connect often fails
Example:

STM32_Programmer_CLI -c port=SWD freq=1000 ap=1 mode=UR reset=HWrst

Error: Unable to get core ID
Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

---

2) DA Discovery occasionally succeeds if timed very precisely at power-up
When I hit the timing correctly, CubeProgrammer logs:

16:03:53:401 : Start Debug Authentication Sequence
16:03:53:402 : SDMOpen : 723 : open : SDM API v1.0
16:03:53:402 : SDMOpen : 724 : open : SDM Library version v1.3.0
16:03:53:405 : open_comms : 607 : open : Asserting target reset
16:03:53:405 : open_comms : 615 : open : Writing magic number
16:03:53:405 : open_comms : 636 : open : De-asserting target reset
16:03:53:405 : open_comms : 671 : open : Communication with the target established successfully
16:03:53:405 : discovery: target ID.......................:0x485
16:03:53:405 : discovery: SoC ID..........................:0x00000000_38323634_30335112_00450059
16:03:53:406 : discovery: SDA version.....................:1.0.0
16:03:53:406 : discovery: Vendor ID.......................:STMicroelectronics
16:03:53:406 : discovery: PSA lifecycle...................:ST_LIFECYCLE_CLOSED
16:03:53:406 : discovery: PSA auth version................:1.0
16:03:53:406 : discovery: ST HDPL1 status.................:0xa
16:03:53:407 : discovery: ST HDPL2 status.................:0xa
16:03:53:407 : discovery: ST HDPL3 status.................:0x0
16:03:53:407 : discovery: Token Formats...................:0x200
16:03:53:407 : discovery: Certificate Formats.............:0x201
16:03:53:407 : discovery: cryptosystems...................:Ecdsa-P256 SHA256
16:03:53:407 : discovery: ST provisioning integrity status:0xeaeaeaea
16:03:53:407 : discovery: permission if authorized...........:Full Regression
16:03:53:407 : discovery: permission if authorized...........:Level 3 Intrusive Debug
16:03:53:409 : discovery: permission if authorized...........:Level 2 Intrusive Debug
16:03:53:410 : discovery: permission if authorized...........:Level 1 Intrusive Debug
16:03:53:410 : discovery: permission if authorized...........:Forced Download

 

This appears to confirm that:
- the board is **CLOSED**
- the DA provisioning integrity is **valid**
- the device expects **certificate-based DA**
- the current provisioned permissions include **Full Regression** and **Intrusive Debug**

---

3) Full Regression fails immediately after Discovery
I then attempt Full Regression using either the GUI, `regression.bat/sh`, or CLI with the official H7S78-DK certificate/key files from the package:

STM32_Programmer_CLI.exe -c port=SWD speed=fast per=a key=.\Keys\key_3_leaf.pem cert=.\Certificates\cert_leaf_chain.b64 debugauth=1

 

These are the same key/certificate file names used by the official H7S78-DK `regression.sh` script, and `per=a` is the ST-documented permission/action for **Full Regression**.

The failure is consistently one of:

open_comms : Unable to detect DBGMCU Mailbox
Error:
Debug Authentication Failed

or

open_comms : No response from the target
open_comms : The target is unable to boot on RSS_DA or is in OPEN mode
open_comms : Failed to open communication with the target
Error:
Debug Authentication Failed

 

The device is not OPEN — successful Discovery reports **CLOSED** — so it appears the target can briefly expose the DA path at startup but cannot reliably re-enter **RSS_DA / DBGMCU mailbox** for the actual action command.

 

Additional observations
- I tried multiple **`per=`** values (regression and debug-reopen related), but they all fail at the same DA bring-up stage.
- I tried lower SWD speeds and hardware reset modes.
- I understand that **Discovery** and **Full Regression** are separate DA service invocations, so it seems possible the board can briefly answer Discovery at startup but fails to re-expose the **DBGMCU mailbox** for the second DA transaction.
- I usually run the OEMiROT 'provisioning.sh' script to flash my application in 'Open' mode. I began these experiments because I noticed that I couldn't perform a regular 'mass erase' and wanted to see if closing/opening allowed mass erase to work without going through provisioning.

 

What I am asking ST to help with
1. Why can Discovery occasionally succeed in CLOSED state, but Full Regression always fails immediately afterward with mailbox / RSS_DA errors?
2. Is there a known issue on **STM32H7S78-DK / STM32H7S7L8H6H** where the target can briefly expose the DA path at power-up but fail to re-enter it for the action command?
3. Is there a recommended recovery procedure (power sequence, BOOT0/RSS boot, etc.) for this specific failure mode?
4. Is **STM32CubeProgrammer v2.19.0** known to have H7RS DA issues here, and should I use a different version?

 

Thank you very much for any assistance!

 

5 REPLIES 5
R_1
Associate III

Wow I still don't have a solution but I have some interesting results today as I work towards recovering the processor.

I ran the following command:

STM32CubeH7RS\Projects\STM32H7S78-DK\ROT_Provisioning\DA> STM32_Programmer_CLI.exe -c port=SWD speed=fast per=a key=.\Keys\key_3_leaf.pem cert=.\Certificates\cert_leaf_chain.b64 debugauth=1

If I run this command, I get the following output:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.19.0
      -------------------------------------------------------------------

Permission request submitted : a

Key file path submitted : .\Keys\key_3_leaf.pem

Certificate file path submitted : .\Certificates\cert_leaf_chain.b64


Start Debug Authentication Sequence

Open SDM Lib
SDMOpen                       :   624 : open       : SDM API v1.0

SDMOpen                       :   625 : open       : SDM Library version v1.2.0

open_comms                    :   513 : open       : Asserting target reset

open_comms                    :   517 : open       : Writing magic number

open_comms                    :   537 : open       : De-asserting target reset

open_comms                    :   573 : open       : No response from the target

open_comms                    :   574 : open       : The target is unable to boot on RSS_DA or is in OPEN mode

open_comms                    :   575 : open       : Failed to open communication with the target

Error:
Debug Authentication Failed


BUT I noticed that if I manually hold reset line until the statement "open_comms : 537 : open : De-asserting target reset", and release the reset line at this point, then the process reaches:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.19.0
      -------------------------------------------------------------------

Permission request submitted : a

Key file path submitted : .\Keys\key_3_leaf.pem

Certificate file path submitted : .\Certificates\cert_leaf_chain.b64


Start Debug Authentication Sequence

Open SDM Lib
SDMOpen                       :   624 : open       : SDM API v1.0

SDMOpen                       :   625 : open       : SDM Library version v1.2.0

open_comms                    :   513 : open       : Asserting target reset

open_comms                    :   517 : open       : Writing magic number

open_comms                    :   537 : open       : De-asserting target reset

open_comms                    :   584 : open       : Communication with the target established successfully

response_packet_lock
discovery: permission if authorized...........:(a/14) ==> Full Regression
discovery: permission if authorized...........:(b/2) ==> Level 3 Intrusive Debug
discovery: permission if authorized...........:(c/1) ==> Level 2 Intrusive Debug
discovery: permission if authorized...........:(d/0) ==> Level 1 Intrusive Debug
discovery: permission if authorized...........:(e/127) ==> Forced Download
SDMOpen                       :   624 : open       : SDM API v1.0

SDMOpen                       :   625 : open       : SDM Library version v1.2.0

open_comms                    :   513 : open       : Asserting target reset

open_comms                    :   517 : open       : Writing magic number

open_comms                    :   537 : open       : De-asserting target reset

open_comms                    :   573 : open       : No response from the target

open_comms                    :   574 : open       : The target is unable to boot on RSS_DA or is in OPEN mode

open_comms                    :   575 : open       : Failed to open communication with the target

Error:
Debug Authentication Failed

 

R_1
Associate III

Ok problem solved. So here is the final command and log. I had to, before running the command, manually hold the reset line.

Then at the first

open_comms                    :   537 : open       : De-asserting target reset

, I had to manually release the reset line.

Then, at the exact right moment of the next "open_comms : 513 : open : Asserting target reset", I had to manually assert/de-assert the reset line.

Failing to adjust the reset line at the exact times would cause the communication to break!

\STM32CubeH7RS\Projects\STM32H7S78-DK\ROT_Provisioning\DA> STM32_Programmer_CLI.exe -c port=SWD speed=fast per=a key=.\Keys\key_3_leaf.pem cert=.\Certificates\cert_leaf_chain.b64 debugauth=1
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.19.0
      -------------------------------------------------------------------

Permission request submitted : a

Key file path submitted : .\Keys\key_3_leaf.pem

Certificate file path submitted : .\Certificates\cert_leaf_chain.b64


Start Debug Authentication Sequence

Open SDM Lib
SDMOpen                       :   624 : open       : SDM API v1.0

SDMOpen                       :   625 : open       : SDM Library version v1.2.0

open_comms                    :   513 : open       : Asserting target reset

open_comms                    :   517 : open       : Writing magic number

open_comms                    :   537 : open       : De-asserting target reset

open_comms                    :   584 : open       : Communication with the target established successfully

response_packet_lock
discovery: permission if authorized...........:(a/14) ==> Full Regression
discovery: permission if authorized...........:(b/2) ==> Level 3 Intrusive Debug
discovery: permission if authorized...........:(c/1) ==> Level 2 Intrusive Debug
discovery: permission if authorized...........:(d/0) ==> Level 1 Intrusive Debug
discovery: permission if authorized...........:(e/127) ==> Forced Download
SDMOpen                       :   624 : open       : SDM API v1.0

SDMOpen                       :   625 : open       : SDM Library version v1.2.0

open_comms                    :   513 : open       : Asserting target reset

open_comms                    :   517 : open       : Writing magic number

open_comms                    :   537 : open       : De-asserting target reset

open_comms                    :   584 : open       : Communication with the target established successfully

[00%]   discovery command
[10%]   sending discovery command
[20%]   receiving discovery
response_packet_lock
[40%]   loading credentials

.\Keys\key_3_leaf.pem

.\Certificates\cert_leaf_chain.b64
[50%]   sending challenge request
[60%]   receiving challenge
response_packet_lock
[70%]   signing token

 the submitted permissions are : a
SDMAuthenticate               :  1391 : client     : Found 3 certificates

response_packet_lock
response_packet_lock
response_packet_lock
[80%]   sending response
[90%]   receiving status
response_packet_lock
SDMAuthenticate               :  1492 : client     : Authentication successful

[100%]  finished authentication

Debug Authentication Success

 

Jocelyn RICARD
ST Employee

Hello @R_1,

Sorry to come late. As stated in other posts, you must connect the reset line of the STLink to your target device to have Debug Authentication working.

Best regards

Jocelyn

R_1
Associate III

Hello @Jocelyn RICARD ,

Thank you very much for your response. 
I have two st-link headers available on my board (I only plug the st-link into one of the headers):

R_1_0-1777471278964.png

Here is where the JTRST line connects to the processor:

R_1_1-1777471483756.png

 

Are you saying that nRST also needs to be connected to the ST-LINK SYS_JTRST?

I noticed now I can communicate with the processor consistently but I am having difficulty performing an erase during provisioning (note that this 'open' provisioning worked consistently before I 'closed' then reopened the device):

AppliCfg with python script
=====
===== Provisioning of OEMiROT boot path
===== Application selected through env.sh: Applications/ROT/OEMiROT_Appli
===== Product state must be Open. Execute  /ROT_Provisioning/DA/regression.sh if not the case.       
===== DTCM/ITCM_AXI_SHARE is going to be forced to 0 for the provisioning steps
===== (if needed uncomment DTCM/ITCM_AXI_SHARE lines with the wished value in the ob_flash_programming script).
=====

Step 0: Preliminary stage

   * Define product state value (* default choice)
       Default product state is going to be applied
TEST >>OPEN <<

Step 1: Configuration management

   * OEMiROT_Config.obk generation:
       From TrustedPackageCreator ^(OBkey tab in Security panel^).
       Select OEMiROT_Config.xml^(Default path is /ROT_Provisioning/OEMiROT/Config/OEMiROT_Config.xml^)
       Warning: Default keys must NOT be used in a product. Make sure to regenerate your own keys!   
       Run Keygen script to randomly regenerate your own keys (Keys/*.pem)
       Update the configuration (if/as needed) then generate OEMiROT_Config.obk file
       Press any key to continue...

   * Configure OEMiROT_Config.xml for OPEN
   * Force the update of OEMiROT_Config.obk


Step 2: Image generations

   * Configure OEMIROT_Boot project as OEMIROT...

   * Boot firmware image generation
       Open the OEMiROT_Boot project with preferred toolchain and rebuild all files.
       At this step the project is configured for OEMiROT boot path.
       Press any key to continue...


   * Configure the Firmware binary input file in OEMiROT_Code_Image.xml...
   * Configure the Image output file in OEMiROT_Code_Image.xml...
   * Code firmware image generation:
       Open the OEMiROT_Appli project with your preferred toolchain
       Rebuild all files. The appli_enc_sign.hex file is generated with the postbuild command        
       Press any key to continue...

Step 3: Provisioning

   * Force DTCM/ITCM_AXI_SHARE to 0...
       Successful

   * Provision the .obk files...
       Successful obk provisioning
       (see obkey_provisioning.log for details)

   * Programming the option bytes and flashing the image...
        Error when trying to "Write OEMiROT_Appli Code"
        Programming aborted

=====
===== Error while executing "Write OEMiROT_Appli Code".
===== See ob_flash_programming.log for details. Then try again.
=====
[❌] Provisioning command failed: Encountered a bad command exit code!



Here is the ob_flash_programming.log contents:

OPTION BYTE PROGRAMMING VERIFICATION:

Option Bytes successfully programmed

Time elapsed during option Bytes configuration: 00:00:02.602
Application image programming in download slots
Write OEMiROT_Appli Code
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.19.0
      -------------------------------------------------------------------

ST-LINK SN  : 0030001F3137510239383538
ST-LINK FW  : V3J17M10B6S1
Board       : STLINK-V3SET
Voltage     : 3.23V
SWD freq    : 8000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID   : 0x485
Revision ID : Rev Y
Device name : STM32H7RSxx
Flash size  : 64 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : 0xE3

Opening and parsing file: zephyr_enc_sign.hex


Memory Programming ...
  File          : zephyr_enc_sign.hex
  Size          : 382.15 KB
  Address       : 0x90200000



Erasing memory corresponding to sector 0:
Erasing external memory sectors [32 37]
Error: failed to erase memory


Error: failed to erase memory


Additionally, even with the device back in 'Open' I am not able to perform an erase in Cube Programmer. I always get the error: "Mass erase operation failed.Please verify flash protection." Do you know how I can perform a mass erase? In Cube I have the following external loader set:

Screenshot 2026-04-24 151655.png

None of the WRP option bytes that are visible in Cube Programmer are set:

R_1_2-1777472294948.png

R_1_3-1777472321309.png

 

 Thanks again!

Jocelyn RICARD
ST Employee

Hello @R_1 ,

According to the trace, you are using a STLinkV3 set.

According to UM2448 : "STLINK V3SET does not manage the JTAG TRST signal"

So, you should just connect STLink's T_NRST to the NRST of the STM32H7S

About option bytes the whole flash is set in write protection.

You should set all WRPx bits to remove this protection and it should work again.

Best regards

Jocelyn