Development recommendations using TrustZone

Development approaches

There are two developer approaches:

Single-developer approach: The developer (customer) is in charge of developing secure and nonsecure application. The user application can be protected by using RDP level 1 or RDP level 2.
Figure 12. Single-developer approach
Dual-developer approach: The first developer (customer 1) is in charge to develop the secure application and its associated nonsecure callable library (.lib/.h), and to provide a predefined linker file to the second developer (customer 2) who is in charge to develop the nonsecure application. This secure application is then loaded in the STM32L5/U5/U3 secure flash memory and protected using RDP level 0.5 to prevent further access to the secure memory region of the device. The second developer (customer 2) then starts his development on a preprogrammed STM32L5/U5/U3 using a linker file and the nonsecure callable library provided by customer 1.
When the RDP level is set to level 0.5, the customer 1 who provisions the secure flash memory part, must also think about the way to enable the JTAG/SWD for the nonsecure side (for customer 2) after booting in the secure side. For this reason, the customer 1 must implement a switch function that handovers to the nonsecure flash memory, to allow the customer 2 to develop the nonsecure part, and then may be to lock the device to RDP level 1 or level 2.
Figure 13. Dual-developer approach

For more details, refer to sections 'Product life-cycle' and 'Software intellectual property protection and collaborative development' in the document AN5347_General-info.html#id_13614__entry_kq3_jtd_wkb or AN5347_General-info.html#id_13614__entry_vrc_1mc_4qb.

Using nonsecure peripherals

When a peripheral is allocated to the nonsecure world, both secure and nonsecure applications can access the peripheral registers.

In the nonsecure world , TrustZone for Armv8-M considerations are totally transparent for the developer. On the secure‑world side, the application must ensure that all system resources required by the peripheral are preconfigured, or available to the nonsecure world (such as GPIO, NVIC or DMA).

Using secure peripherals

When a peripheral is allocated to the secure world, only secure register accesses are granted. Interrupt handling must be managed in the secure world only. Two different software development approaches can be adopted depending on the software interaction requirements between secure and nonsecure projects to use this peripheral.

When working with peripherals that do not require specific interaction with the nonsecure world, the secure world drives them as a standard peripheral without any specific considerations.

If interactions between nonsecure and secure worlds are required to drive the secure peripherals, the secure application must provide nonsecure callable APIs and callbacks to the nonsecure world.

Conclusion

The Arm TrustZone technology partitions hardware into secure and nonsecure worlds.

Through the IDAU that defines fixed memory-map security attribution with the user configurable SAU and other features (in flash memory and GTZC), all of STM32 MCU resources are configurable in both secure and nonsecure worlds, including the memory map, the flash memory, SRAM, external memories, peripherals, and peripheral interrupts.

Revision history

Table 13. Document revision history
Date	Version	Changes
11-Oct-2019	1	Initial release.
14-Oct-2019	2	Updated Figure 6. Memory and peripheral data access rules summary .
10-Feb-2020	3	Updated: Introduction Section 2.1 Overview Section 2.2 Security states Section 3.1 Activation of STM32L5 Series TrustZone Section 3.3 SAU and IDAU Figure 3. Address security attribution Section 3.3.1 STM32L5 Series IDAU and memory aliasing Table 1. IDAU memory map address security attribution on STM32L5 Series Section 3.3.2 STM32L5 Series SAU Section 4 Security configurations on STM32L5 Series devices Section 4.1 Security configuration of the Flash memory Section 4.1.1 Secure watermark of the Flash memory Section 4.1.2 Flash memory block based Section 5.1 Default security status Section 5.2 Memory and peripheral security access rules Figure 6. Memory and peripheral data access rules summary Section 6 Boot and root secure services (RSS) Section 7.1 RDP level 1 and Section 7.2 RDP level 0.5 Section 8 Security features available only when TrustZone is enabled Section 9 TrustZone deactivation Section 10.1, Section 10.2 and Section 10.3 Section 11 Conclusion Added: Section 1.1 Reference documents Figure 5. Default Flash bank security state though the option bytes Table 4. Instruction fetch rules Section 10 Development recommendations using TrustZone
2-Mar-2020	4	Updated: Section 7.1 RDP level 1 Section 7.2 RDP level 0.5 Added Section 9.1 TrustZone/RDP deactivation demonstration using the STM32CubeProgrammer.
28-Sep-2021	5	Updated: Title and whole text to integrate the STM32U5 Series Reference documents in Section 1 General information Section 3.3.2 STM32L5 and STM32U5 SAU Section 4 Security configurations on STM32L5 and STM32U5 Series Section 7 Readout protection (RDP) when TrustZone enabled Section 8 Security features available only when TrustZone is enabled Section 9.1.2 TZEN/RDP regression with a boot from RSS Section 11.1 Development approaches Added: Section 7.3 RDP level 2 Section 7.4 RDP transitions with OEM keys (STM32U5 only) Section 9.1.3 TZEN/RDP regression when RDP level 1 is locked by an OEM1 Key Section 10 Demonstration of RDP transitions using OEM keys (STM32U5 only)
08-Apr-2022	6	Updated: Various typo
24-Feb-2025	7	Updated the entire document to introduce STM32U3 series. Updated the document title. Corrected various typos.