Error while running the STiROT+OEMuROT example on stm32H533 Nucleo board

[Amruta D]

Hello,

I am using the Nucleo STM32H533RE board for booting with the two stage boot path for which I am using the ST template code and referring the following   https://wiki.st.com/stm32mcu/wiki/Security:OEMiRoT_OEMuRoT_for_STM32H7S . 

I am able to run the provisioning script successfully but when I am connecting the serial terminal to verify the serial data sent out by the board, I am getting an error saying “[ERR] read:Wrong OBK HDPL2 cfg” as seen in below image:

I tried with the following things:

1. Regenerating the OEMuROT OBK files manually using stm32 trusted package creator
2. Running the regression script to erase the flash and again running the provisioning script
3. Verified if the key file names matches the script references

Can someone help me with this issue.

Let me know if any other details are required.

 

Thanks,

Amruta

[Jocelyn RICARD]

Hello ​@Amruta D ,

You are mentioning STM32H7S wiki but you are using STM32H533.

You may need to follow the getting started wiki for STM32H573 : How to start with STiRoT_OEMuRoT on STM32H573 - stm32mcu

which is very close to STM32H533 (only flash and RAM size change).

What did you change compared to default configuration ?

Normally it should work out of the box.

One important point to raise in context of OEMuROT. The generation of OEMuROT obk file is more complex than a simple click in the TrustedPackageCreator.

You can see this in the provisioning.bat script

%stm32tpccli% -obk Config\OEMuRoT_Config_Keys.xml  => Will generate the OEMuRoT_Config_intermediate.bin file in binary containing only the OEMuROT keys

Then

%stm32tpccli% -pb ST\OEMuRoT_ST_Settings_1.xml => will generate an OEMuROT_Config.bin containing the keys and the hash of the keys

and finally

%stm32tpccli% -obk ST\OEMuRoT_ST_Settings_2.xml => Will insert the OEMiROT_Config.bin in an obk structure in OEMuRoT_Config.obk

Normally all these operations are done in provisioning.bat script so, if even if you changed a key it should work.

As you are in open mode it is possible to use debugger to check what is actually done just before the error. This may give a clue

 

Best regards

Jocelyn

[Amruta D]

Hello ​@Jocelyn RICARD,

Thanks for replying.

I am using the boot path (STM32Cube\Repository\STM32Cube_FW_H5_V1.5.1\Projects\NUCLEO-

H533RE\ROT_Provisioning\STiROT_OEMuROT) correctly for running the provisioning script

on the board STM32H533RE so the flash and RAM sizes are  correctly defined in the

respective flash_layout header file for this processor. So, I didn’t change any default

configurations. I also verified the respective paths in the env batch file. 

The keys and image generation is done using provisioning batch script but just to verify I also tried

using the stm32 trusted package creator to generate them. I generated all the binary files you

mentioned above from the xml configuration files.

As you mentioned to check what is exactly happening before the error, I am currently trying to

debug the issue.

I can see that the computed SHA-256 key of the current HDPL2 data does not match with the

stored SHA-256 key due to which the error is getting triggered. I will dig into this further and try to

find the exact issue. Let me know if you have anything to say on this.

 

Regards,

Amruta

 

 

 

[Jocelyn RICARD]

Hello ​@Amruta D ,

Ok I could reproduce your issue probably doing the same mistake as you did :)

The point is that when provisioning in open state, you will connect the CN7 pins to set BOOT0 to VDD to provision the obk.

What you probably did (like me) is to remove the jumper and reset.

When staying in open state, you actually need to keep BOOT0 tied to VDD.

As BOOT_UBE is set to 0xC3 (STiROT), in order to boot on STiROT and not on OEMuROT you must boot on system flash.

If you boot in user flash, you will boot in HDPL1. So, when reading HDPL2  OBK you will read only zeros (this is what I noticed when debugging). This explains the error.

If after provisioning you leave the jumper in place it will boot properly

Best regards

Jocelyn

 

 

 

[Amruta D]

Hello ​@Jocelyn RICARD ,

You are right, I was removing the jumper and disconnecting the connection of BOOT0 pin with Vdd

after provisioning was done successfully due to which wrong HDPL2 OBK was read. 

When I am leaving the jumper as it is, I am able to boot the board correctly and getting the correct

serial data out from the board as seen below:

 

Thank you so much for helping. 

 

Regards

Amruta