cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeProgrammer Default DA Configuration, TZ Enabled, DA Fails - STM32H563 OEMiROT

dekukas_abb
Associate II

Hi,

I am trying to get the OEMiROT example projects running on STM32H563 from "STM32CubeH5\Projects\NUCLEO-H563ZI\Applications\ROT". The provision.bat script fails after writing option bytes (probably after enabling TZ) and tries to reconnect to the MCU, which is where the script fails.

To get around this, I am trying to do what "provisioning.bat" does manually. I compiled the "OEMiROT_Boot", "OEMiROT_Appli_TrustZone" apps (secure and non-secure) in STM32CubeIDE and the expected .hex are generated. Here are the steps I followed next in STM32CubeProgrammer:

  1. Product state set to "Provisioning". At this stage, STM32CubeProgrammer confirms if default DA configuration is to be used. I select yes. Successful.
  2. Enable TrustZone. Successful.
  3. Write "OEMiROT_Config.obk". Successful.
  4. Flash all .bin and .hex compiled in "STM32CubeH5\Projects\NUCLEO-H563ZI\Applications\ROT".
  5. Set product state to "iROT Provisioned". MCU disconnects, reset problems reported, debugger cannot reconnect.
  6. I try DA. DA is in Certificate authentication mode, as expected in TZ enabled mode.
  7. I try to use the "key_3_leaf.pem" and "cert_leaf_chain.b64" provided in "STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\DA_Default_Config\STM32H5". I try Full Regression but it fails - "Debug Authentication failed". I chose the key and certificate from "DA_Default_Config\" as I chose default DA configuration in step 1. Trimmed log attached.

This failure is not letting me continue with the OEMiROT examples and concepts in general. I believe this error has currently nothing to do with the OEMiROT I am trying to run.

Which key/certificate combination should be used when default DA configuration in STM32CubeProgrammer is chosen? Can some combination in "STM32CubeH5\Projects\NUCLEO-H563ZI\ROT_Provisioning\DA" help?

 

1 ACCEPTED SOLUTION

Accepted Solutions
Jocelyn RICARD
ST Employee

Hello @dekukas_abb ,

The issue here is that you enabled TrustZone after first default provisioning.

With default provisioning, the programmer detects if TrustZone is enabled or not.

If not enabled, it provisions the password hash and not the public key hash.

Then you change to TrustZone.

Debug authentication trace shows:

11:02:22 : discovery: ST provisioning integrity status:0xeaeaeaea

This check is only DA integrity check (this is a hash check of payload data).

But payload is not adapted to the TrustZone setting. This is why it fails.

I'm afraid your Nucleo is bricked now.

You should have better  shared the provisioning.log file to understand why it was not working in the first place.

Best regards

Jocelyn

View solution in original post

6 REPLIES 6
Jocelyn RICARD
ST Employee

Hello @dekukas_abb ,

The issue here is that you enabled TrustZone after first default provisioning.

With default provisioning, the programmer detects if TrustZone is enabled or not.

If not enabled, it provisions the password hash and not the public key hash.

Then you change to TrustZone.

Debug authentication trace shows:

11:02:22 : discovery: ST provisioning integrity status:0xeaeaeaea

This check is only DA integrity check (this is a hash check of payload data).

But payload is not adapted to the TrustZone setting. This is why it fails.

I'm afraid your Nucleo is bricked now.

You should have better  shared the provisioning.log file to understand why it was not working in the first place.

Best regards

Jocelyn

dekukas_abb
Associate II

Hello @Jocelyn RICARD ,

Thank you for your prompt support. I got my hands on another board (not Nucleo but our prototype based on STM32H563 1MB variant). And tried "provisioning.bat" again. It was successful. I may have had the MCU in "Provisioning" state and executed the "provisioning.bat", which is why it could have failed earlier.

I have now run into another issue. "provisioning.bat" was successful but the MCU after reset reports on Serial output:

[INF] TAMPER Activated<\r><\n> [INF] BANK 1 secure flash [0, 22] : OB [0, 14]<\r><\n> [ERR] Unexpected value for secure flash protection<\r><\n>

I think this problem occurs because in default "OEMiROT_Config.xml", the value of Flash size is wrong for the 1MB variant. What is your opinion?

<?xml version="1.0" encoding="UTF-8"?> <Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SCHVerif.xsd"> <Obdata> <Info> <Title>OEMiRoT configuration</Title> <ObDestAddress>0x0FFD0160</ObDestAddress> <DoEncryption>0</DoEncryption> <GlobalAlign>16</GlobalAlign> <FlashStart>0x0C000000</FlashStart> <FlashSize>0x100000</FlashSize> /* Changed from 0x200000 */ <FlashSectorSize>0x2000</FlashSectorSize>

I wanted to retry the updated "OEMiROT_Config.obk" with changed "OEMiROT_Config.xml", after full regression of the MCU but, again, the Debug Authentication does not work. Here's the script output:

------------------------------------------------------------------- STM32CubeProgrammer v2.19.0 ------------------------------------------------------------------- Permission request submitted : a Key file path submitted : .\Keys\key_3_leaf.pem Certificate file path submitted : .\Certificates\cert_leaf_chain.b64 Password file path submitted : .\Binary\password.bin 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"
View more


It looks like the MCU is not responding to the debug commands. What could be the problem here?

Please let me know if you prefer addressing this in another post, moving forward.

 

I have some observations to add to my previous query:

  • It seems like the constant "DEVICE_1M_FLASH_ENABLE" in "flash_layout.h" of OEMiROT is not applied in "OEMiROT_Config.xml" by postbuild script when OEMiROT is compiled. After making the changes to the .xml file and regenerating .obk file, "provisioning.bat" and "regression.bat" are working perfectly on our STM32H563_1MB.
  • The below serial output from OEMiROT suggests that there is a 64KB gap in settings applied by .obk file and the constants in "flash_layout.h". We have commented the line defining "MCUBOOT_OVERWRITE_ONLY" in "flash_layout.h" to activate swap mode and scratch area size of 64KB. Thus, it seems like the .obk file is unaware of the swap area of 64KB that we have enabled. 
[INF] BANK 1 secure flash [0, 22] : OB [0, 14]<\r><\n>
Jocelyn RICARD
ST Employee

Hello @dekukas_abb,

good progress indeed !

Just in case you are using STM32CubeIDE, you should use .sh scripts. These are the one updated by the scripts.

Best regards

Jocelyn

 

 

Hello @Jocelyn RICARD ,

This helped a lot. I wanted to stick to .bat scripts and I adapted the "ob_flash_programming.bat" with "ob_flash_programming.sh". Everything works well now. Thank you very much!

 

Jocelyn RICARD
ST Employee

Great! Thank you for your feedback!