STM32H563 Debug Authentication Failure with OEMiRoT and product state PROVISIONED

linglinqin · ‎2026-02-04

I'm using the link below to select boot path and do secure boot device provisioning for my STM32H563 board:

https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_OEMiRoT_Boot_path_on_STM32H563

Boot path is configured as follows:

I have run provisioning.bat, the product state was set to PROVISIONED. The provisioning was successfull, with logs at the end of ob_flash_programming.log:

OPTION BYTE PROGRAMMING VERIFICATION:

Option Bytes successfully programmed
Time elapsed during option Bytes configuration: 00:00:01.334
Programming success

However, inside ob_flash_programming.log, it also shows:

PROGRAMMING OPTION BYTES AREA ...
Warning: Option Byte: boot_ube, value: 0xB4, was not modified.
Warning: Option Byte: hdp2_end, value: 0x0, was not modified.
Warning: Option Byte: secbootadd, value: 0xC0000, was not modified.
Warning: Option Byte: secwm2_end, value: 0x0, was not modified.
Warning: Option Byte: sram2_ecc, value: 0x0, was not modified.
Warning: Option Byte: sram2_rst, value: 0x0, was not modified.
Warning: Option Byte: sram3_ecc, value: 0x1, was not modified.
Warning: Option Byte: swap_bank, value: 0x0, was not modified.
Warning: Option Byte: wrpsgn2, value: 0xFFFFFFFF, was not modified.

Could this indicates that some of the option bytes (e.g., secbootadd) may not be successfully written to flash?

Below is the Option Bytes overview after provisioning:

Everything looks ok, but SECBOOTADD = 0x00000000, it should be 0xC000000 when TZEN = 1 and UBE = B4 (OEMiRoT). Could this be the reason that I can't do Debug Authentication discover and perform DA correctly?

While doing Debug Authentication Discover, it shows error as above image: The target is unable to boot on RSS_DA or is in OPEN mode. Will Debug Authentication requries RSS_DA access which needs to start from SECBOOTADD at 0xC000000?

If so, is there any way to open debug and recover this board at this stage?

Running regression.bat also failed now. It shows a similar error as doing Debug Authentication above:

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
"regression script failed"

Jocelyn RICARD · ‎2026-02-06

Hello @linglinqin ,

My first guess would be that you didn't connect the reset pin of your target to your STLink V2.

Can you check this?

Best regards

Jocelyn

linglinqin · ‎2026-02-06

Thank you for the reply Jocelyn.

I checked with our HW team, we haven't connected the reset pin in our ST-Link cable. Only these 4 pins are connected: VAPP, SWDIO, SWCLK and GND.

W/o connecting the reset pin of the target to ST-Link V2, could this be the reason that we failed to write 0xC000000 to SECBOOTADD, or the reason that while doing Debug Authentication, the MCU failed to boot on RSS_DA?

What is the purpoose of the reset pin here?

Thanks again!

Jocelyn RICARD · ‎2026-02-07

Hello @linglinqin ,

The reset pin control is necessary for the Debug Authentication procedure. To establish this communication with RSS_DA, the programmer writes a specific value at specific address and reset.

The fact that you see SECBOOTADD to 0 is because you are connected in non secure. In such state you don't have access to all the option bytes even in reading.

Best regards

Jocelyn

linglinqin · ‎2026-02-10

Hi Jocelyn,

Thank you so much. You're amazing! We connected the reset pin to ST-Link cable, RSS_DA access established, and Debug Authentication is successfully done. Much appreciated for your help!

Best Regards