How to disable TrustZone in STM32L5xx devices during development phase

1. What is TrustZone^®?

The STM32L5 Series is based on the Cortex^®-M33 core, which is part of the Arm Cortex^®-M group of 32-bit RISC cores. It implements the Armv8-M mainline architecture. The processor implements ARM TrustZone^® technology, using the ARMv8-M Security Extension.

The Arm TrustZone^® technology partitions the system into two regions: one is secure world and another is non-secure world. The division of secure and non-secure worlds is memory map based. All the available microcontroller resources including Flash memory, SRAM, external memories, peripherals and interrupts, are allocated to either the secure or non-secure world. After planning the security attribution of these resources, non-secure world only accesses non-secure memories and resources, while secure world is able to access all memories and resources in both worlds, including secure and non-secure resources.

TrustZone^® technology for Arm Cortex-M processors enables robust levels of protection at all cost points for IoT devices. The technology reduces the potential for attack by isolating the critical security firmware and private information from the rest of the application. It provides the perfect starting point for establishing a device root-of-trust based on Platform Security Architecture (PSA) guidelines.

2. How TrustZone^® is enabled in STM32L5xx devices?

All STM32L5xxx devices support the TrustZone^®. TrustZone^® is disabled by default in all STM32L5xx devices. It is activated by setting the TZEN option bit in the FLASH_OPTR register when RDP level is set to Level 0.

3. Steps to disable the TrustZone^® in STM32L5xx devices

Disabling TrustZone^® can be needed during development phase. Once TrustZone^® is activated on the device, it can only be deactivated during an RDP regression to level 0 (either from RDP level 1 to level 0 or from RDP level 0.5 to level 0). So, disabling TrustZone^® results in a full chip mass erase: the sample is virgin, corresponding to the production state. Disabling the TrustZone^® can be done only through Bootloader or debug interface (JTAG/SWD). This guarantees that a malicious software cannot disable the TrustZone^®.

Note: If the device is in RDP level 2, all debug features are disabled, the boot from system memory (bootloader mode) is no longer available. Consequently, in RDP level 2, it is impossible to disable the TrustZone^®.

To do TZEN deactivation, the part must already be in RDP level 1 or level 0.5. As a reminder, when TrustZone^® is activated:

The Cortex-M33 CPU is in secure state after reset and the boot address must be in a secure address.
In RDP level 0.5 and level 1:
- When the CPU is in secure state, it is not possible to connect to the target through JTAG/SWD, so TZEN/RDP regression is not possible.
- When the CPU is in non-secure state, connection to the target through JTAG/SWD and RDP regression are possible.

For boot from user Flash memory, if the non-secure code is not called by the secure code, the CPU always remains in the secure state and the RDP regression cannot be done through JTAG / SWD in such cases.

In the following, we assume that the boot is done from the user Flash memory of an STM32L5.

Before programming RDP level 0.5 or RDP level 1, the user must always ensure that the secure application calls the non-secure application so that the connection to the target is possible.

Step 1: Use the GPIO_IOToggle_TrustZone example provided within the STM32CubeL5. Follow the various guidelines provided in the example readme file, and make sure that the example is running correctly.

Step 2: Set RDP level to level 1.

Note that once the RDP level is set to level 1:

Only hot-plug connection is possible (in order to not reset the CPU during connection).
A power supply different from ST-LINK must be used in order to be able to connect to the target. For more details, please refer to the section 7.1 RDP level 1 in the AN5347.

Step3: Do TZEN and RDP regression

If step 1 was skipped, the only way to do regression is through JTAG (or SWD) /bootloader with a boot from RSS (See Note below). For further details about the different boot options, refer to the STM32L552xx and STM32L562xx advanced Arm^®-based 32-bit MCUs reference manual (RM0438).

If the boot is based on the BOOT0 pin level, it is possible to boot from RSS and do the regression.
If the boot is based on the nBOOT0 option bit, it is no longer possible to program the option bytes, and hence not possible to boot from RSS. It is therefore not possible to do regression.

Note: This is because there is a jump from RSS (secure) to Bootloader (non-secure), so with a boot from RSS the CPU state is guaranteed to switch from secure to non-secure and connection to the target is possible.