Debugging with STM32U3 and OEMiRoT_Appli_TrustZone

AdsBot · ‎2026-06-03

Hi ST,

I can't seem to get debugging to function when following the above named example on a nucleo-u385RG-Q using CubeIDE and CubeProgrammer. The guidance on the README is vague when it needs to be clear - for starters what is the 'offset of the firmware execution slot'?

"1. The most efficient way to develop and debug an application is to boot directly on user flash in RDL level 0 by setting with STM32CubeProgrammer the RDP to 0xAA and the SECBOOTADD to (0x0C006000 + offset of the firmware execution slot)."

This example was designed by ST to work on a clean board, wouldn't you know the exact value? There is also nothing about adjusting the secure watermarks so the debugger does not hit a secure area by default and hard fault - I had to find that particular nugget stashed in a completely seperate project.

Many of us delving into STM32 development are not well versed in low level memory management, especially navigating across Secure / Non Secure / Bootloader sections - hence the value of a 'functioning' example out of the box to help us understand. This isn't the first example project I've come across that hasn't worked except by some 'gotcha' that wasn't covered in the documentation.

Appreciate any help with this example and look forward to getting better at this!

Frantz LEFRERE · ‎2026-06-03

Hello AdsBot,
First I would recommand to read those article.

https://wiki.st.com/stm32mcu/wiki/Security:OEMiRoT_OEMuRoT_for_STM32U3
https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_OEMiRoT_on_STM32U3
Following the How to start will install the OEMiROT and OEMiRoT_Appli_TrustZone
it will install everything and understand the memory mapping.
If you select RDP 0, in the installation you can then connect and debug the OEmiROT and also the application secure and non secure ( debug in hotplug mode only)
All the option byte will be automatically configured.
So you can check the memory mapping and the option byte configuration.

"1. The most efficient way to develop and debug an application is to boot directly on user flash in RDL level 0 by setting with STM32CubeProgrammer the RDP to 0xAA and the SECBOOTADD to (0x0C006000 + offset of the firmware execution slot)."

In fact this note purpose is somehow a tips to develop and debug the application without using the OEMiROT.
The "offset of the firmware execution slot" depends if you have change the memory layout.
The address definition are :
NUCLEO-U385RG-Q\Applications\ROT\OEMiROT_Appli_TrustZone\Secure_nsclib\appli_region_defs.h
NUCLEO-U385RG-Q\Applications\ROT\OEMiROT_Appli_TrustZone\Secure_nsclib\appli_flash_layout.h

The simple way to find this address is to check after the generation application OEMiROT_Appli_TrustZone\Secure
OEMiROT_Appli_TrustZone
By default it should be : 0x0C016400 (FLASH_AREA_0_OFFSET+BL2_HEADER_SIZE)

I hope this helps !
Best regards,

Frantz

AdsBot · ‎2026-06-07

Hi Frantz,

Thanks for getting back to me, appreciate the help.

I started with those guides and was able to get the project running fine, moving up to RDP2 and back down, however it's this debugging step that's caught me out. Without debugging I have no hope of integrating my own application within this secureboot + trustzone architecture.

I tried the default value you mentioned but haven't have any luck, was that for the MCU I mentioned? (U385RG-Q)

Here are the values from my appli_region_defs / appli_flash_layout:

#define FLASH_BASE_S 0x0C000000 /*!< FLASH secure base add */

#define FLASH_AREA_0_OFFSET 0x18000 /* Secure app image primary slot */

#define BL2_HEADER_SIZE (0x400) /*!< Appli image header size */

It's not clear where 0c006000 is derived, or how you got to 0x0C016400

Should it be 0x0C006000 + (0x18000 + 0x400 )= 0x0C01E400 (as you instructed)
Or,
Should it be 0x0C000000 + (0x18000 + 0x400) = 0x0C018400 (closer to the value you mention)

I've had no luck with these values either, but it's hard to know what is breaking with the generic hardfault I'm getting, is it that memory location, is it the debugging approach.

I've spun up some version of what I think a 'hotplug debugger' should be doing (ie. no reset, no download of new image etc to 'attach' to a running session instead of starting a new one) but without an official cubeIDE guide I'm unsure if I've missed anything. Did you have any resources you could reference?

Worth mentioning too that when I attempted to change the SECBOOTADD value in CubeProgrammer it was not clear that I had to untick 'boot lock', apply, change the value, then apply. The error I get when trying to simply update the fields does not make this clear, nor is it mentioned in the guides you linked, or the tips on the github. It's 'assumed knowledge' like this that has tripped me up often in my development journey with ST so far, and I'm sure others as well, so hopefully with my feedback this can improve (easier said than done I'm sure).

Thanks again for your help,
Adam

Frantz LEFRERE · ‎2026-06-08

Hi @AdsBot,

"I started with those guides and was able to get the project running fine, moving up to RDP2 and back down,"
Do those step again and select RDP 0. This will alows you to debug in hotplus mode ( without download)

Then you've possibility to change the SECBOOTADD to bypass the secure boot ( keeping all the option byte configuration done by the previous config).
You have to untick the bootlock this is describe in the reference manual ( I would recommand to understand the option byte configuration) to be able to change the secboot address/

Then the address value is the one where is linked your secure application.In cubeIDE after compilation of the secure application you can just check with the build analyzer

Best regards,

Frantz