Wild issue! STM32H7S78 stuck after DA provisioning!
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 Failedor
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!