STM32H563: Unable to Regress or Debug Authenticate

[beartronics]

Hello,

(previous post was marked as spam - I don't know why, so I'm posting again...)

I've been working on Provisioning my STM32H563 and after 3 weeks of not touching it, I am unable to perform Full Regression or Debug Authentication on my password-provisioned Nucleo Board. I tried using the generated bash scripts from CubeIDE/MX (which are using STM32_Programmer_CLI) and also STM32CubeProgrammer GUI.

I remember before the vacation, I could open and close the Board at will. I always used the same password.bin.

Provisioning always happened using the generated provisioning.sh script.

Here is the Output of STM32CubeProgrammer (I found it has more info than dbg_auth.sh), after trying Discovery and Full Regression:

17:21:34 : Start Debug Authentication Sequence
17:21:34 : SDMOpen : 609 : open : SDM API v1.0
17:21:34 : SDMOpen : 610 : open : SDM Library version v1.1.0
17:21:34 : open_comms : 501 : open : Asserting target reset
17:21:34 : open_comms : 505 : open : Writing magic number
17:21:34 : open_comms : 515 : open : De-asserting target reset
17:21:34 : open_comms : 567 : open : Communication with the target established successfully
17:21:34 : discovery: target ID.......................:0x484
17:21:34 : discovery: SoC ID..........................:0x00000000_00000000_00000000_00000000
17:21:34 : discovery: SDA version.....................:2.4.0
17:21:34 : discovery: Vendor ID.......................:STMicroelectronics
17:21:34 : discovery: PSA lifecycle...................:ST_LIFECYCLE_CLOSED
17:21:34 : discovery: PSA auth version................:1.0
17:21:34 : discovery: ST HDPL1 status.................:0xffffffff
17:21:34 : discovery: ST HDPL2 status.................:0xffffffff
17:21:34 : discovery: ST HDPL3 status.................:0xffffffff
17:21:34 : discovery: Token Formats...................:0x200
17:21:34 : discovery: Certificate Formats.............:0x201
17:21:34 : discovery: cryptosystems...................:ST Password
17:21:34 : discovery: ST provisioning integrity status:0xeaeaeaea
17:21:34 : discovery: permission if authorized...........:Full Regression
17:21:42 : UR connection mode is defined with the HWrst reset mode
17:21:42 : Start Debug Authentication Sequence
17:21:42 : SDMOpen : 609 : open : SDM API v1.0
17:21:42 : SDMOpen : 610 : open : SDM Library version v1.1.0
17:21:42 : open_comms : 501 : open : Asserting target reset
17:21:42 : open_comms : 505 : open : Writing magic number
17:21:42 : open_comms : 515 : open : De-asserting target reset
17:21:42 : open_comms : 567 : open : Communication with the target established successfully
17:21:42 : [00%] discovery command
17:21:42 : [10%] sending discovery command
17:21:42 : [20%] receiving discovery
17:21:42 : [40%] loading credentials
17:21:42 : [50%] sending challenge request
17:21:42 : [60%] receiving challenge
17:21:42 : SDMAuthenticate : 1298 : client : Found 1 certificates
17:21:42 : [80%] sending ST password
17:21:42 : [90%] receiving response
17:21:42 : Error: Debug Authentication Failed
17:21:42 : Disconnected from device.
17:21:42 : ST-LINK SN : 0032002B3132511238363431
17:21:42 : ST-LINK FW : V3J15M6
17:21:42 : Board : NUCLEO-H563ZI
17:21:42 : Voltage : 3.25V
17:21:42 : 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.

----------------------------------------------------------------------

What could be the issue here? In Line 36, it says that there is 1 certificate found - I never installed a certificate as far as I can tell. And even if that was the case, it should be regressable using default generated keys and certs?

Thank you and best regards,
Stefan

[Jocelyn RICARD]

Hello @beartronics ,

according to the discovery log, the password was well provisioned :

ST provisioning integrity status:0xeaeaeaea

Also, this "Found 1 certificate" is normal.

Here is the trace I get:

  11:29:56 : SDMOpen                       :   602 : open       : SDM API v1.0
  11:29:56 : SDMOpen                       :   603 : open       : SDM Library version v1.1.0
  11:29:56 : open_comms                    :   495 : open       : Asserting target reset
  11:29:56 : open_comms                    :   499 : open       : Writing magic number
  11:29:56 : open_comms                    :   509 : open       : De-asserting target reset
  11:29:56 : open_comms                    :   561 : open       : Communication with the target established successfully
  11:29:56 : [00%]	discovery command
  11:29:56 : [10%]	sending discovery command
  11:29:56 : [20%]	receiving discovery
  11:29:56 : [40%]	loading credentials
  11:29:56 : [50%]	sending challenge request
  11:29:56 : [60%]	receiving challenge
  11:29:56 : SDMAuthenticate               :  1317 : client     : Found 1 certificates
  11:29:56 : [80%]	sending ST password
  11:29:56 : [90%]	receiving response
  11:29:56 : [100%]	authentication successful
  11:29:56 : SDMAuthenticate               :  1382 : client     : Authentication successful
  11:29:56 : Debug opened successfully. the target will be connected.
  11:29:56 : Disconnected from device.
  11:29:56 : ST-LINK SN  : 0033003E3232511239353236
  11:29:56 : ST-LINK FW  : V3J15M6
  11:29:56 : Board       : NUCLEO-H563ZI
  11:29:56 : Voltage     : 3.28V
  11:29:56 : Warning:  Connection to AP 0 requested and failed, Connection established with AP 1
  11:29:56 : SWD freq    : 8000 KHz
  11:29:56 : Connect mode: Power Down
  11:29:56 : Reset mode  : Hardware reset
  11:29:56 : Device ID   : 0x484
  11:29:56 : Revision ID : --
  11:29:56 : Debug in Low Power mode enabled.
  11:29:56 : SFSP Version: v2.5.0
  11:29:56 : UPLOADING OPTION BYTES DATA ...
  11:29:56 :   Bank          : 0x00
  11:29:56 :   Address       : 0x40022050
  11:29:56 :   Size          : 112 Bytes
  11:29:56 :   Bank          : 0x01
  11:29:56 :   Address       : 0x40022070
  11:29:56 :   Size          : 16 Bytes
  11:29:56 :   Bank          : 0x02
  11:29:56 :   Address       : 0x40022080
  11:29:56 :   Size          : 16 Bytes
  11:29:56 :   Bank          : 0x03
  11:29:56 :   Address       : 0x400220e0
  11:29:56 :   Size          : 16 Bytes
  11:29:56 :   Bank          : 0x04
  11:29:56 :   Address       : 0x400221e0
  11:29:56 :   Size          : 16 Bytes
  11:29:56 :   Bank          : 0x05
  11:29:56 :   Address       : 0x40022090
  11:29:56 :   Size          : 8 Bytes
  11:29:56 :   Bank          : 0x06
  11:29:56 :   Address       : 0x400220f0
  11:29:56 :   Size          : 8 Bytes
  11:29:56 :   Bank          : 0x07
  11:29:56 :   Address       : 0x400221f0
  11:29:56 :   Size          : 8 Bytes
  11:29:56 :   Bank          : 0x08
  11:29:56 :   Address       : 0x400220f8
  11:29:56 :   Size          : 8 Bytes
  11:29:56 :   Bank          : 0x09
  11:29:56 :   Address       : 0x400221f8
  11:29:56 :   Size          : 8 Bytes
  11:29:56 : UPLOADING ...
  11:29:56 :   Size          : 1024 Bytes
  11:29:56 :   Address       : 0x8000000
  11:29:56 : Read progress:
  11:29:56 : Data read successfully

So, the only thing I can think off is that your password was modified at some point.

Can you check that you didn't regenerate the password file with another password ?

Best regards

Jocelyn

[beartronics]

Hello @Jocelyn RICARD ,

thank you for the reply. I am certain that the project was not modified after last provisioning the board (I use git to track all changes) - which is what stumbles me the most. Before provisioning the board for the first time, the password was initially changed to 32 character length - which I save in my Password manager (and of course also in the xml file). Only this password was used to provision the board.

In the meantime, I tried changing the password back to the one generated by default (0123456789012345), but also no success unlocking, for obvious reasons...

Is there any other possibility that I could get this exact error message, other than "bits toppling over" in the Flash?

I guess I will have to acquire another Nucleo Board then... but thank you for trying to help!

Best regards
Stefan

[Jocelyn RICARD]

Hello @beartronics ,

Can you confirm you already reopened the same device with this 32 bytes password ?

Looking into AN6008 I can read:

"A password (maximum length of password is 128 bits/16 bytes)."

If you have a way to update your code on your target through a bootloader, you can create a code that will perform the regression. In this case, no need for password.

Best regards

Jocelyn

[beartronics]

---

@Jocelyn RICARD wrote:

"A password (maximum length of password is 128 bits/16 bytes)."

---

Wow that's some good info. Thanks! I definitely was provisioning and regressing the device again back and forth using the 32 length password, so I wonder how I could even close it. Seems I went overboard with security here!

But nevermind, because however, the second part of your reply

---

@Jocelyn RICARD wrote:

If you have a way to update your code on your target through a bootloader, you can create a code that will perform the regression. In this case, no need for password.

---

caught my interest. I indeed have a bootloader running that is capable of firmware update.

Can you point me to resources (or better: code) on how to regress directly inside STM32 Code? Much appreciated!

Best regards,
Stefan

[Jocelyn RICARD · Accepted solution]

Hello @beartronics ,

let me share with you a code I made recently to demonstrate provisioning from embedded code.

It also contains the code to perform regression from embedded code.

This should help you recovering your device.

Best regards

Jocelyn

[beartronics]

Hi @Jocelyn RICARD ,

thank you very much for your help. That worked!

For some reason, I could not input any of the four menu options (tried multiple Serial Terminals), so I changed it up and simply called Regression() directly.

I also had to change the Clock Input (HSE) from 8 to 25MHz, because my Nucleo is configured to run from external 25MHz Oscillator, just in case anybody finds this thread and can't get the code to run.

Thank you again!

Best regards,
Stefan

[Jocelyn RICARD]

Hello @beartronics ,

yes the example is supposed to be run on Nucleo H563 and interaction done through the virtual com port setup at 115200. It has to be adapted to your own environment.

Good to see this allowed you to recover your board

Best regards

Jocelyn