STM32H503 cannot perform regression

[RGari]

Hello.  I am experimenting with securing a STM32H503 using password authentication, which will ultimately be an automated process.

I created a simple password for testing and created the password hash in board_password.bin and da_password.bin

(just for comparison, I also used Segger's advice and tried certutil and the resulting board_password.bin file is identical, so I'm pretty sure the password hash worked).

I set the chip to PRODUCT_STATE provisioning and programmed the chip with the password using the following:

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug  -ob PRODUCT_STATE=0x17

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug -w board_password.bin 0x8FFF000

Both of these commands succeeded with no errors

As recommended, I locked the OTP so I wouldn't accidentally damage it by overwriting by:

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug -ob LOCKBL=0x1

Again, no errors

Finally I set PRODUCT_STATE to PROVISIONED and again, no errors

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug  -ob PRODUCT_STATE=0x2E

The problem comes when I try to perform regression.  

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug pwd=da_password.bin debugauth=1

I believe it is acting like the password was not accepted

-------------------------------------------------------------------
STM32CubeProgrammer v2.17.0
-------------------------------------------------------------------

Start Debug Authentication Sequence

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

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

discovery: permission if authorized...........:(a/14) ==> Full Regression
SDMOpen : 602 : open : SDM API v1.0

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

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

please enter your password file path
[50%] sending challenge request
[60%] receiving challenge
SDMAuthenticate : 1308 : client : Error parsing password file (da_password.bin)

Error:
Debug Authentication Failed
response_packet_lock
response_packet_lock
response_packet_lock

user_password.bin is exactly 16 bytes in length

I created the da_password.bin file using ST's AppliCfg.py script, along with the board_password.bin file.  Examining the da_password file it seems to contain user_password.bin's contents with a header that was specified in the sample create_password script with the -h 0x000000800C000000 switch.  I assume that is correct.

The current state of the chip is:

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug debugauth=2

-------------------------------------------------------------------
STM32CubeProgrammer v2.17.0
-------------------------------------------------------------------

Start Debug Authentication Sequence

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

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

discovery: target ID.......................:0x474
discovery: SoC ID..........................:0x00000000_35343637_30325101_00620057
discovery: SDA version.....................:1.2.0
discovery: Vendor ID.......................:STMicroelectronics
discovery: PSA lifecycle...................:ST_LIFECYCLE_IROT_PROVISIONED
discovery: PSA auth version................:1.0
discovery: ST HDPL1 status.................:0x11111111
discovery: ST HDPL2 status.................:0x22222222
discovery: ST HDPL3 status.................:0x33333333
discovery: Token Formats...................:0x200
discovery: Certificate Formats.............:0x201
discovery: cryptosystems...................:ST Password
discovery: ST provisioning integrity status:0xffffffff
discovery: permission if authorized...........:(a/14) ==> Full Regression
To select multiple permission/actions:
Using numerical values: List the needed bit numbers, separated by commas without spaces.
Using symbolic letters: List the needed letters by concatenating them without separators.

Debug Authentication: Discovery Success
response_packet_lock

I noticed that provisioning integrity status is 0xffffffff.  What does that mean?  (I see other values mentioned in the forums but not that one).

NOTE that I did NOT flash a bootloader yet--at this point, we are not ready with our bootloader and just want to ship some samples to a customer with our firmware read-out-protected and then if they need to get a new revision they will need to return the sample for regression/reprogramming.  We do intend to eventually use a bootloader and allow for encrypted firmware updates and set to a CLOSED state but our code for that is not ready yet.  So we are attempting to utilize this similar to the normal Readout protection available on other chip models as a temporary measure.

For the test I didn't actually flash any firmware into this chip (just the DA password)--just wanted to get familiar with moving between product states and performing regression first.

[MarcelP]

Hello,

did you actually Check that your device is in fact in OPEN state after the regression?
I am using the CubeProgrammer v2.20 for an STM32H503 now and the regression is NOT working for me.

I use this password file with a 16byte test password:

The CubeProgrammer signals that the "Debug opened successfully", but the target is still in CLOSED state.
This is the log output when I perform the regression:

16:07:11 : UR connection mode is defined with the HWrst reset mode
16:07:12 : UR connection mode is defined with the HWrst reset mode
16:07:12 : Start Debug Authentication Sequence
16:07:12 : SDMOpen : 624 : open : SDM API v1.0
16:07:12 : SDMOpen : 625 : open : SDM Library version v1.2.0
16:07:12 : open_comms : 513 : open : Asserting target reset
16:07:12 : open_comms : 517 : open : Writing magic number
16:07:12 : open_comms : 537 : open : De-asserting target reset
16:07:12 : open_comms : 584 : open : Communication with the target established successfully
16:07:12 : [00%] discovery command
16:07:12 : [10%] sending discovery command
16:07:12 : [20%] receiving discovery
16:07:12 : [40%] loading credentials
16:07:12 : [50%] sending challenge request
16:07:12 : [60%] receiving challenge
16:07:12 : SDMAuthenticate : 1391 : client : Found 1 certificates
16:07:12 : Debug opened successfully. the target will be connected.
16:07:12 : Disconnected from device.
16:07:12 : ST-LINK SN : 57FF6E067186535448181487
16:07:12 : ST-LINK FW : V2J45S7
16:07:12 : Board : --
16:07:12 : Voltage : 3.21V
16:07:12 : Error: Unable to get core ID
16:07:12 : Error: Cannot connect to access port 1! If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode. If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it.

A related answer from the ST-Support from 24.7.2025 this year states, that the CubeProgrammer currently has a bug, and that you can not perform the regression with the CubeProgrammer. But I am not sure if he just simply refers so the bug in v2.17 that should be fixed with 2.18. As of now, I can not perform the regression with 2.20.

Any updates or hints, maybe I did sth wrong, would be appreciated.

[MaTz]

Hi,
for your case, I think the missing puzzle piece is that regression can only be triggered from CLOSED state, I think. I use this in production, similar to your usecase (just as a readout protection)..set the chip in closed state and then try doing a regression. Before all of this, to not lock down the chip without possible recovery (if DA doesn't work) you can flash a program that will do a regression triggered by anything you have on your board (UART message, button, or similar). Just be aware that after you program the password once, you can never change it for that specific chip.
Happy locking and unlocking :)

[MaTz]

Hi,

the bug in the programmer was fixed in 2.18 AFAIK. In your case, I think your problem is that you're trying to use certificate DA instead of password based DA. Try that and see :)

[MarcelP]

Thanks for the answer.

Of course my chip is in closed state, but the regression will still not perform.

Best Regards

Marcel

[MarcelP]

Thanks for trying to help me.

No really I think im doing it right. Im in the password Debug-Authentication dialog and i am pointing to my password file, as stated in the dialog hint. My controller is in CLOSED state and the regression will not work.

[MaTz]

In my case, I never performed a successful regression in the GUI when I was trying that due to the bug. After that I just used CLI commands as it is easier in production anyway. 

I use:
STM32_Programmer_CLI.exe -c port=SWD debugauth=2
for discovery, and 

STM32_Programmer_CLI.exe -c port=SWD debugauth=1

for regression, respectively.
The former will ask you for your path to the password file, or you can provide the path upfront with pwd="pathToPassword.bin"

Hope this helps :)

[MarcelP]

Even using the STM32_Programmer_CLI will not open my chip.

As suggested by you, I used this command to perform the regression. It reports a success at the end:

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD debugauth=1
-------------------------------------------------------------------
STM32CubeProgrammer v2.20.0
-------------------------------------------------------------------

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
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

please enter your password file path
C:\Users\MarcelP\Desktop\OBKeys\da_password.bin
[50%] sending challenge request
[60%] receiving challenge
response_packet_lock
SDMAuthenticate : 1391 : client : Found 1 certificates

Debug Authentication Success

After that, performing the discovery command again still shows my chip as CLOSED:

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD debugauth=2
-------------------------------------------------------------------
STM32CubeProgrammer v2.20.0
-------------------------------------------------------------------

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: target ID.......................:0x474
discovery: SoC ID..........................:0x00000000_38343338_3133510A_006B0041
discovery: SDA version.....................:1.2.0
discovery: Vendor ID.......................:STMicroelectronics
discovery: PSA lifecycle...................:ST_LIFECYCLE_CLOSED
discovery: PSA auth version................:1.0
discovery: ST HDPL1 status.................:0x11111111
discovery: ST HDPL2 status.................:0x22222222
discovery: ST HDPL3 status.................:0x33333333
discovery: Token Formats...................:0x200
discovery: Certificate Formats.............:0x201
discovery: cryptosystems...................:ST Password
discovery: ST provisioning integrity status:0xffffffff
discovery: permission if authorized...........:(a/14) ==> Full Regression
To select multiple permission/actions:
Using numerical values: List the needed bit numbers, separated by commas without spaces.
Using symbolic letters: List the needed letters by concatenating them without separators.

Debug Authentication: Discovery Success

[MarcelP]

Ok, I successfully performed a regression now. The problem was with my password file.

This was my original password file:

But I saw in the ROT_Provisioning example Project from the STM32H5 BSP, that there was a bit missing in the header of my file (see the 0x80 at position 3).
This is the password file now that works.

With this, I could successfully perform a regression with the GUI STM32CubeProgrammer.

But man I am a bit angry that there is no documentation about the structure of this password.bin file that you have to use to perform the regression. What does this bit in the header do?

Anyway, the original problem is solved, and thanks for the support.

[MaTz]

Yeah now that you mention it, I vaguely remember having similar issues with the password file. I think that bit is part of the length of the password and is missing in the header for some reason. 

The lack of documentation is a real issue. I was told that there would be documentation in the future (when I was contacting support regarding my issues). But still nothing changed :(

Anyways I'm happy I was able to nudge you in the right direction, and I hope others find this thread when having issues :)