STM32CubeProgrammer Default DA Configuration, TZ Enabled, DA Fails - STM32H563 OEMiROT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 2:37 AM
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:
- Product state set to "Provisioning". At this stage, STM32CubeProgrammer confirms if default DA configuration is to be used. I select yes. Successful.
- Enable TrustZone. Successful.
- Write "OEMiROT_Config.obk". Successful.
- Flash all .bin and .hex compiled in "STM32CubeH5\Projects\NUCLEO-H563ZI\Applications\ROT".
- Set product state to "iROT Provisioned". MCU disconnects, reset problems reported, debugger cannot reconnect.
- I try DA. DA is in Certificate authentication mode, as expected in TZ enabled mode.
- 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?
Solved! Go to Solution.
- Labels:
-
Cryptography
-
Secure Manager
-
STM32 Security
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 2:57 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 2:57 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 6:05 AM
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"
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 8:38 AM
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>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 12:57 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-23 11:36 PM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-24 2:08 AM
Great! Thank you for your feedback!
