cancel
Showing results for 
Search instead for 
Did you mean: 

STMU385 - OEMiROT_Appli_TrustZone example - building as combined secure + non-secure doesn't work.

JVan .3
Associate II

I'm working with the STM32U385/375 for a project, and have started my investigation into how to convert it to a secure root of trust application by working with the OEMiROT examples.

In stock form it works well. The provisioning works, the update over the y-modem link works just fine, etc. However, I want to build a combined binary and not deal with separate non-secure and secure binaries to apply for an update.

Accordingly, I changed MCUBOOT_APP_IMAGE_NUMBER in OEMiROT_Boot/Inc/flash_layout.h from 2 to 1, like so:

#define MCUBOOT_APP_IMAGE_NUMBER 1 /* 1: S application only if FLASH_NS_PARTITION_SIZE = 0 ,
else S and NS application binaries assembled in one single image.
2: Two separated images for S and NS application binaries. */

The build works fine, the first part of the provisioning script works fine, the appropriate value is updated in appli_flash_layout.h, and the programming begins. However, it fails with this error:

=====
===== Error while executing "Programming the option bytes and flashing the images...".
===== See "ob_flash_programming.log" for details. Then try again.
=====

I looked in the log, where I see this:

"Application images programming in download slots"
Set boot address @0x1800C0
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.21.0                  
      -------------------------------------------------------------------

ST-LINK SN  : 003C003D3333511631363730
ST-LINK FW  : V3J16M7
Board       : NUCLEO-U385RG-Q
Voltage     : 3.28V
SWD freq    : 8000 KHz
Connect mode: Hot Plug
Reset mode  : Software reset
Device ID   : 0x454
Revision ID : Rev Z
Device name : STM32U3xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : --
Debug in Low Power mode enabled

      -------------------------------------------------------------------
        Choose flashing speed for Cortex M33 series.(default speed=Reliable)                  
      -------------------------------------------------------------------

Error: File does not exist: oemirot_tz_app_init_sign.bin

 

I looked in the file system and I don't see that file. I don't see in the provisioning script where it ought to be generated. Any ideas what's going on here and how to fix it?

 

7 REPLIES 7
Jocelyn RICARD
ST Employee

Hello @JVan .3 ,

I made the test and confirm that is an issue.

The oemirot_tz_app_init_sign.bin is actually oemirot_tz_ns_app_init_sign.bin

So, normally if you rename manually oemirot_tz_ns_app_init_sign.bin by oemirot_tz_app_init_sign.bin it should work.

I will raise this 

Best regards

Jocelyn

I tried this, but something seems to go wrong.

Specifically, this is the output on the console:

[INF] TAMPER Activated
[INF] Flash operation: Op=0x0, Area=0x0, Address=0x0
[INF] Starting bootloader OEMiROT
[INF] Checking BL2 NV area
[INF] Checking BL2 NV area header
[INF] Checking BL2 NV Counter consistency
[INF] Consistent BL2 NV Counter 0  = 0x0
[INF] Swap type: none
[INF] Starting validation of primary slot(s)

The device never finishes validation, and hangs like this. Did you see a different result?

Jocelyn RICARD
ST Employee

Hello @JVan .3 ,

I can reproduce the issue.

I made some investigation and provide the result to internal case for fixing.

I don't have immediate workaround unfortunately.

Best regards

Jocelyn

 

stst9187
Associate III

Hi JVan .3

Which IDE are you using for testing OEMiROT ?

Thank you.

Regards,

Marco

STMCube IDE version 2.0.0

Regards,
Josh
JVan .3
Associate II

Is there any progress on investigating this issue?

Jocelyn RICARD
ST Employee

Hello @JVan .3,

here is the feedback I just got from dev team.

"In fact we have intentionally decided to not support this 'assembled' mode on U3 at start of development activity, but unfortunately the wiki documentation mention it by mistake and compile flag is still present sometimes. I would recommend:

- either to use the existing 2 separated images OEMiRoT example, with same authentication keys for S and NS images (with OEMiRoT_Appli_Trustzone).

- or to use the existing 'no isolation' application OEMiRoT example (with OEMiRoT_Appli)"

Best regards

Jocelyn