2025-12-23 11:12 AM
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?
2026-01-08 11:41 AM
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
2026-01-12 12:36 PM
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?
2026-01-15 10:01 AM
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
2026-01-19 1:20 AM
Hi JVan .3
Which IDE are you using for testing OEMiROT ?
Thank you.
Regards,
Marco
2026-01-19 7:02 AM
2026-02-03 3:50 PM
Is there any progress on investigating this issue?
2026-02-04 9:52 AM
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