Skip to main content
makturan
Associate II
October 15, 2026
Question

STM32N6 – Password debug authentication with OEMuRoT: STM32CubeProgrammer cannot discover the device ("No device found by ST-Link")

Hello ST Support team,

We are building a product on the STM32N645 with the STM32CubeN6 OEMuRoT secure boot flow (MCUboot-based OEMuRoT, application image in external XSPI2 NOR, executed in place). We want to re-open debug on closed devices with the OEMuRoT password debug authentication (DA), using STM32CubeProgrammer, the way it is shown in ST's videos. CubeProgrammer cannot start the DA on our devices. We wrote our own host tool, and with it the same OEMuRoT firmware opens debug correctly. We need your help to make the standard CubeProgrammer flow work, because it is the procedure we want for production and service.

1. Setup

Item Version / state
MCU STM32N645 (DBGMCU DEV_ID 0x486)
Firmware package STM32CubeN6 [version]; debug_authentication.c of OEMuRoT is unchanged from the reference (same in V1.1.1 to V1.4.1) apart from the points in section 4
STM32CubeProgrammer v2.23.0 (SDM library v1.4.0, SDM API v1.0)
Probe ST-LINK V3SET, firmware V3J16M8B5S1, SWD, NRST connected
Board A Custom board, lifecycle CLOSED_UNLOCKED, OEMuRoT + signed application, DA password hash programmed in OTP
Board B Custom board, lifecycle CLOSED_LOCKED_PROVD

2. What fails with STM32CubeProgrammer

CLI, debug closed (flash boot, application running):

 

STM32_Programmer_CLI -c port=SWD mode=UR debugauth=2
Start Debug Authentication Sequence
Open SDM Lib
No device found by ST-LinkError:
Debug Authentication: Discovery Failed
  • We tried mode=UR, mode=HOTPLUG, reset=HWrst, ap=0, freq=1000 and combinations of them. All of them fail the same way within about one second, right after "Open SDM Lib".
  • We also tried after replugging the ST-LINK, after a board power cycle, and in development boot (debug open). The result was the same.
  • The GUI (Secure Programming → Debug Authentication → Discover) reports "failed to communicate with target".
  • Once, on board A with debug still open, the CLI reached the SDM library, but it took the RSS path instead of the N6 OEMuRoT path: 
    open_comms : Asserting target reset
    open_comms : Writing magic number
    open_comms : De-asserting target reset
    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
    We could not reproduce this run.

psa_sdm.dll contains the N6 strings ("OEDA"/"DAOK", "Failed to open communication with the STM32N6"), so we expect the N6 path to be supported. It never gets that far on our devices.

3. What works with our own host tool (pyOCD + the same ST-LINK)

We implemented the OEMuRoT mailbox protocol directly on AP0 (DBGMCU at 0x80001000; mailbox registers DBG_AUTH_HOST +0x100, DBG_AUTH_DEV +0x104, DBG_AUTH_ACK +0x108):

  1. While the application is running, write "OEDA" to DBG_AUTH_HOST, then pulse NRST.
  2. OEMuRoT answers "DAOK"; then discovery, challenge and the password TLV follow.
  3. OEMuRoT returns status 0. A wrong password returns status 1.
  4. After the application starts (HDPL2), BSEC_DBGCR = 0xB48AB400 and HDPLSR = 0x8A. We can then attach with CubeProgrammer (hot plug, AP1) and with STM32CubeIDE / VS Code (ST-LINK_gdbserver, attach) and debug the application.

So the device side works, and the problem seems to be in how STM32CubeProgrammer / the SDM library reaches the device.

4. Observations and changes on our side

  • AP access on a BSEC-closed device: before any authentication, the ST-LINK returned "No device connected" for every AP0 access. Only the DP answered (DPIDR 0x6BA02477), and AP0 IDR was readable once. AP0 became reachable only after we called HAL_BSEC_UnlockDebug() (BSEC_AP_UNLOCK = 0xB4) in OEMuRoT before waiting for the mailbox request. In the reference code this call happens only after a correct password, so we do not see how a host can post "OEDA" on a closed device. BSEC_DBGCR is still written only after a correct password.
  • After a cold power-up, AP0 stayed closed until the first NRST pulse. We have not explained this yet.
  • Secure debug: our application runs entirely in the secure state, so after a correct password we open both secure and non-secure debug (Sec_Dbg_Auth = HAL_BSEC_SEC_DBG_AUTH, NonSec_Dbg_Auth = HAL_BSEC_NONSEC_DBG_AUTH, HDPL_Open_Dbg = HAL_BSEC_OPEN_DBG_LEVEL_2). The reference opens non-secure debug only.
  • Debug only at HDPL2: after DA, the CubeProgrammer GUI Secure Programming / OTP page loses the connection. Reading the XSPI2 NOR (0x70000000) with -r32 without an external loader fails in CubeProgrammer, although the debugger reads it correctly with pyOCD. We assume this happens because debug opens only at HDPL2 and the tool resets or runs a loader.

5. Questions

  1. What is the supported STM32CubeProgrammer procedure (GUI and CLI options, connection mode, reset mode) for OEMuRoT password DA on STM32N6 in the CLOSED_UNLOCKED and CLOSED_LOCKED_PROVD states? Which minimum versions of STM32CubeProgrammer, the SDM library and the ST-LINK firmware does it need?
  2. Why does the SDM library report "No device found by ST-Link" right after "Open SDM Lib"? How does it decide between the RSS ("magic number") path and the N6 ("OEDA") path?
  3. On a BSEC-closed STM32N6, should AP0 (DBGMCU mailbox) be accessible before BSEC_AP_UNLOCK is written? If not, what is the intended mechanism for the host to post the DA request? Is it acceptable from a security point of view to write BSEC_AP_UNLOCK = 0xB4 before the password check, as long as BSEC_DBGCR is written only after it?
  4. Which password file format does STM32CubeProgrammer expect for N6 OEMuRoT DA, and which tool should generate it?
  5. Is opening secure debug from OEMuRoT (BSEC_DBGCR = 0xB48AB400) after a successful password check the recommended approach when the application runs in the secure state?
  6. After DA, what is the recommended way to read OTP and external NOR with STM32CubeProgrammer without the tool resetting the device into HDPL0/1, where debug is closed?
  7. Is it expected that AP0 stays closed after a cold power-up until the first NRST?

We can provide the full CLI logs (with -vb 3 if useful), our host tool and the OEMuRoT diff on request. We can also run any test sequence you suggest.

Best regards, 

Terms & ConditionsAccessibility statement