STM32H573 STiROT+OEMuROT example failed provisioning.

[Rohit007]

Hi Community,

I’m provisioning an STM32H573 (installed on a NUCLEO-H563ZI board; I replaced H563 with H573). I followed the ST example STiRoT_OEMuROT from STM32Cube FW H5 v1.6.0. During provisioning the script aborts with:

Error when trying to Set SECBOOT_LOCK option byte to 0xC3 (unlock secure boot address)
  Provisioning aborted.

Environment: 
- MCU: STM32H573 (2 MB flash)
- Host tools: STM32_Programmer_CLI v2.19.0
- Product state chosen in provisioning script: OPEN.

after i read the option bytes using STM32_Programmer_CLI -c port=SWD -ob displ 
i found that, 

 

   Product state:

     PRODUCT_STATE: 0xED (Open) 

   BOR Level:

     BOR_LEV      : 0x0 (BOR Level 1, the threshold level is low (around 2.1 V)) 
     BORH_EN      : 0x0  (0x0) 

   User Configuration:

     IO_VDD_HSLV  : 0x0  (0x0) 
     IO_VDDIO2_HSLV: 0x0  (0x0) 
     IWDG_STOP    : 0x1  (0x1) 
     IWDG_STDBY   : 0x1  (0x1) 
     BOOT_UBE     : 0xC3 (ST-iRoT (system flash) selected) 
     SWAP_BANK    : 0x0  (0x0) 
     IWDG_SW      : 0x1  (0x1) 
     NRST_STOP    : 0x1  (0x1) 
     NRST_STDBY   : 0x1  (0x1) 
OPTION BYTES BANK: 1

   User Configuration 2:

     TZEN         : 0xB4 (Trust zone enabled) 
     USBPD_DIS    : 0x1 (Disabled) 
     SRAM2_ECC    : 0x0 (SRAM2 ECC check enabled ) 
     SRAM3_ECC    : 0x1 (SRAM3 ECC check disabled) 
     BKPRAM_ECC   : 0x1 (BKPRAM ECC check disabled) 
     SRAM2_RST    : 0x0 (SRAM2 erase when system reset) 
     SRAM1_3_RST  : 0x1 (SRAM1 and SRAM3 not erased when a system reset occurs) 
OPTION BYTES BANK: 2

   Boot Configuration:

     NSBOOTADD    : 0x80000  (0x8000000) 
     NSBOOT_LOCK  : 0xC3 (The SWAP_BANK and NSBOOTADD can still be modified following their individual rules.) 
     SECBOOT_LOCK : 0xB4 (The BOOT_UBE and SECBOOTADD are frozen. SWAP_BANK can only be modified with TZEN set to 0xC3 (disabled).) 
     SECBOOTADD   : 0xC0004  (0xC000400) 
OPTION BYTES BANK: 3

also, when device goes in boot mode, i am not able to read the option bytes, for reading the option bytes i have to remove boot0 pin from VDD and reset it.

 STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -ob displ
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.19.0                  
      -------------------------------------------------------------------

ST-LINK SN  : 004700463434511634313937
ST-LINK FW  : V3J17M10
Board       : NUCLEO-H563ZI
Voltage     : 3.28V
Error: Unable to get core ID
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.

2nd connect tentative with frequency (8MHz)
ST-LINK SN  : 004700463434511634313937
ST-LINK FW  : V3J17M10
Board       : NUCLEO-H563ZI
Voltage     : 3.29V
Error: Unable to get core ID
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.

Question: what’s preventing `SECBOOT_LOCK=0xC3` from being written? Is it:
- OB protected because ST-iRoT is running and re-writing OBs?
- some required precondition in option bytes I haven’t met?
- needing a different connect sequence (Hotplug/hardRst) or specific CLI version?

also, Please find an attached logs of obkey_provision.log 

[Jocelyn RICARD]

Hello ​@Rohit007 ,

I’m not aware about an issue related to system bootloader

Did you try communicating with to the system bootloader using BOOT0 pin in open state, with and without TrustZone enabled?

Regarding bootloader implementation, you have an example on STM32H563 of a standalone loader using UART/Ymodem

For I2C you can use the openbootloader example STM32Cube_FW_H5_V1.7.0\Projects\STM32H573I-DK\Applications\OpenBootloader\ as base

Best regards

Jocelyn

[Rohit007]

​@Jocelyn RICARD,

I tested access to the system (ROM) bootloader by driving BOOT0 high (open state), both with TrustZone enabled and with it disabled. With TrustZone enabled, the MCU immediately reset when I ran i2cdetect and I could not establish an I²C session with the ROM bootloader. With TrustZone disabled, the same I²C interaction worked and I could communicate with the ROM bootloader without resets.

I believe that maybe, TrustZone is preventing I²C-based access to the ROM bootloader.

[Jocelyn RICARD]

Hello ​@Rohit007 ,

I tested on a STM32H563 and couldn’t reproduce your issue.

Maybe you are using a very old STM32H5 with first version of bootloader ?

Looks like version 0xE3 has a an issue with TrustZone, but this was fixed in next version (see AN2606 Rev70 page 308)

Best regards

Jocelyn

[Rohit007]

Hello ​@Jocelyn RICARD ,

Thank you for the update, and yes i think there is some issue with the bootloader, i just blindly tried the fw upgrade using the system bootloader and yes it is wroking fine. but the same system bootloader does not allow the i2cdetect.

For information the Bootloader version i am getting is 

r ap 1 @0xBF9FAFE 0x00000001 bytes Data 0x000000E4

 

[Jocelyn RICARD]

Hello ​@Rohit007 ,

I’m sorry for late answer.

You can find the I2C source in the openbootloader project example here

Regarding the location of the loader, it is usually not recommended to avec such code in the secure boot application in case an attacked manages to take control of your device through this interface.

Now with i2c interface, the risk is low; Up to you to evaluate this.

Other solutions are : integrate the loader in the application which is the usual way.

Last solution is to implement the loader as a separate application launched by OEMuROT upon specific trigger.

I hope this answers your questions.

Best regards

Jocelyn