Chapter 9 STM32L5 and Nucleo-144

The following chapter focuses on the technical specifics and implementation details of TrustZone-M on a STM32L5 microcontroller. Chapter 10 accompanies this chapter and shows example firmware implementations on a STM32L5.

9.1 Hardware Overview

The cheapest development board with TrustZone-M support I could find was the NUCLEO-L552ZE-Q, which is powered by a STM32L552ZE microcontroller by STMicroelectronics. The hardware:

  • Microcontroller: STM32L552ZET6QU
  • Arm Cortex-M33 at 110 MHz with TrustZone and FPU
  • Internal Flash Memory (512 KB)
  • Internal SRAM1 (192 KB)
  • Internal SRAM2 (64 KB)

The evaluation board provides:

  • Different connectors like USB-Type C, SWD
  • 3 LEDs
  • 2 Push-Buttons
  • On-Board ST-LINKv2-1 debugger and programmer

For the rest of this chapter I am going to refer to the evaluation board as Nucleo, and when I mean explictily the microcontroller I use STM32L5.

Most of the values (memory regions,…) you will see in the next chapters are configurable by the user. I’ll use example values.

9.2 STM32 Product Life Cycle

The life cycle of a product, which contains a STM32L5 as a component, can be a hugely complex: After STM produced the STM32L5 there might be multiple vendors involved to assemble, initialize and provision the final product, before it is sold or delivered to the end user. The product might return to the vendor for Return Material Analysis or might be decomissioned. Different stages of the life cycle have different security requirements. For example, the original vendor might want to program the secure world of a device (e.g. to ensure it’s identity by storing secrets in secure world), but having the provisioning of nonsecure world outsourced to any other vendor.

9.2.1 Readout Protection (RDP)

The different security requirements of each development stage are reflected by Readout Protection (RDP) on STM32 devices. Different STM32 devices have different RDP levels with different features enabled or disabled per level. Transitioning between these levels is only possible in a predefined way. STM32L5 microcontrollers have the following RDP levels:

RDP level Description
  • Debug: Secure and non-secure world.
  • If TZEN=1: Boot address must target secure world.
  • Debug: non-secure world only
  • if TZEN=1: Boot address must target secure world.
  • Access to non-secure flash is allowed during debugging.
  • Access to secure world is (SRAM, Flash) not permitted
  • Boot from SRAM is not permitted
  • Debug: conditional, non-secure world only
  • In Debug: No access to flash or SRAM
  • In User Mode: COde Executing can read, write, erase flash
  • Debug: None
  • Option Bytes are read only.
  • RDP2 level ist final.
  • Limitations booting from SRAM and system memory
  • When booting from flash read, write and erase is allowed from user code
RDP transitions with TrustZone enabled (source: @an5421)

Figure 9.1: RDP transitions with TrustZone enabled (source: 8)

Figure 9.1 shows which transitions are possible in STM32L552x and on which transitions flash is erased. The example given above, where one vendor programs secure world and another one non-secure world, could be mapped by RDP transitions: Vendor 1 in RDP0 programs secure world and increases RDP to 0.5 and then ships the product to vendor 2, who programs non-secure world and increses to RDP 1 or 2. RDP 0.5 was introduced for these use cases and is only available, when TrustZone is enabled.

9.3 Option Bytes

Option Bytes are STM32L5s way to implement reset-enduring system configuration. These option bytes are automatically read back by the system on PoR. Using the STM32CubeProgrammer option bytes can be programmed for example via ST-Link. There are User Manuals and descriptions for STM32CubeProgrammer available on the product website.

To set the configuration bytes, the board must be plugged in and connected. To successfully connect to the board, the ST-Link drivers and the STM32CubeProgrammer (see chapter 10.1) need to be installed.

The option bytes are part of the flash information block. They can be reprogrammed through the flash interface registers at 0x5002 2000 - 0x5002 23FF (secure) and 0x4002 2000 - 0x4002 23FF (non-secure). There is a dedicated programming sequence you can find in [5, p. 190].

See chapter 10.2.1 for an example how option bytes are configured using the STM32CubeProgrammer.

9.4 Memory Map

In chapter 4.5 a high-level segmentation of the address space applicable to Arm6-M, Armv7-M and Armv8-M was introduced. The STM32L5 actually respects this Arm recommendations:

Table 9.1: STM32L5 Memory Map - Overview
region Description
C-Bus access region 0x0000 0000 ..
Access to flash, SRAM,… through C-Bus (with ICACHE)
SRAM 1 and SRAM2 0x2000 0000 ..
0x3FFF 0000
Access to SRAM1 and 2 through S-Bus
Peripherals 0x4000 0000 ..
0x5FFF 0000
Access to Peripherals
FMC Bank 1 0x6000 0000 ..
0x7FFF 0000
Access to external memories managed through FSMC10
FMC Bank 3 and OCTOSPI 0x8000 0000 ..
0x9FFF 0000
Access to external memories managed through FSMC and OCTROSPI
Private Peripheral Bus, System region 0xE000 0000 ..
Access to Cortex-M33 system control and debug.

The memory map is divided into 512 MB sized regions, as Arm recommends for the system address map. The C-Bus access region is cached, where the first half of it is fixed (0x0000 0000-0x0FFF FFFF) and the other half can be used to remap external memories to be cached by ICACHE (0x1000 0000-0x1FFF FFFF). SRAM1 and SRAM 2 are accessible through the second 512 MB region (0x2000 0000 - 0x3FFF 0000). STM32L5x periperals are mapped to the region (0x4000 0000 - 0x5FFF 0000), wheras - in the Private Peripheral Bus region - Cortex-M33 peripherals and core registers are available (0xE000 0000 - 0xFFFF FFFF).

Some more details on the PPB can be found in chapter 4.5.

More on Arm Memory System:

  • Chapter 9.4: STM32L5: Memory Map
  • Chapter 4.5: Arm Architecture: Memory System

9.4.1 STM32L5: IDAU and SAU

When TrustZone (TZEN=1 option byte) memory is either attributed as secure (S), non-secure (NS) or non-secure callable (NSC).The STM32L5 has one IDAU, which is used to further subdivide each of the regions from table 9.1 and attributes them to either NS and NSC areas, as you can see on figure 9.2.

STM32L552xx IDAU memory mapping.  [@rm0438 p. 87]

Figure 9.2: STM32L552xx IDAU memory mapping. [5, p. 87]

More on Implementation Defined Attribution Unit:

  • Chapter 5.5: IDAU and SAU: Security attribution
  • Chapter 9.4: STM32L5: Memory Map

STMicroelectronics decided not to predefine regions in IDAU as secure, but only split memory into NSC and NS. This leaves the choice to the developer to further decide which of the regions should be attributed secure (S).

As mentioned in the basics chapter on TrustZone-M (see chapter 5), the division of secure and non-secure worlds is - in contrast to TrustZone-A - memory map based. That might be a little bit difficult to wrap the head around, so let’s look at an example how flash can be split up (the values are from example 1, see chapter 10.2):

The STM32L5 has 512 KB Flash. Since we can address Flash bytewise, we need 0x0008 0000 addresses to address the whole Flash (512 * 1024). In figure 9.2 we see FLASH twice:

  • 1: 0x0800 0000 - 0x0807 FFFF (NS)
  • 2: 0x0C00 0000 - 0x0C07 FFFF (NSC)

You can address whole Flash in both regions. When the system resets and TrustZone is enabled, whole memory (including 1 and 2) is secure by default. The next step for the developer is to configure SAU to downgrade up to 8 memory regions to either NSC or NS. In the IDAU and SAU security attribution logic, the highest of both attributes wins (see chapter 5.5). If a developer needs to define a NS region, she needs to downgrade a region in the SAU, which was also defined NS in IDAU (for the Flash example, that would be 1).

The example downgrades two regions in the SAU for Flash:

  • Non-Secure
    • IDAU attributes flash at 0x0800 0000 to 0x0807 FFFF as NS
    • The NS region in SAU is a subset of the NS region in IDAU, which is 0x0804 0000 to 0x0807 FFFF
    • The rest of it is attributed as S, because SAU is per-default S.

Because the other alias for Flash (region number 2) is attributed NSC in IDAU, you can’t downgrade it further than to NSC, so you need to choose region number 1 to define a NS region.

  • Non-Secure Callable:
    • IDAU attributes flash at 0x0C00 0000 to 0x0C07 FFFF as NSC.
    • NSC region in SAU is a subregion of the NSC region in IDAU, which is 0x0c03 E000 to 0x0c03 ffff.
    • The rest of it is attributed as S, because SAU is per-default S.

Remember: On PoR, when TrustZone is enabled, whole memory is secure by default in SAU. This is configurable in the ALLNS bit of the SAU_CTRL register. (see chapter 8.2). This leaves the regions, which are not downgraded in the SAU, as Secure.

This results in the final mapping of the whole 512 KB flash you can see on the far right on figure 9.2.

Flash Mapping Example 1

Figure 9.3: Flash Mapping Example 1

More on Security Attribution Unit:

  • Chapter 5.5: IDAU and SAU: Security attribution
  • Chapter 6.3: CMSIS: ROM segment and Boot Process
  • Chapter 8.2: SAU Initialization
  • Chapter 9.4: STM32L5: Memory Map

In CMSIS the setup of SAU is done in the parition_<device>.h (see on GitHub). (see 8.2). The final Flash security attribution:

Table 9.2: SAU final memory map of example
Type security attributes description
Flash NSC 0x0C03 E000 - 0x0C03 FFFF
Flash NS 0x0804 0000 - 0x0807 FFFF
Flash S 0x0C00 0000 - 0x0C03 DFFF

9.5 Global TrustZone Controller

The Global TrustZone Controller is a block on a STM32L5, which contains subblocks and components relevant for system security configuration. There are 3 subblocks, which are described later in this chapter.

IDAU and SAU is only one layer of security on a STM32L5. IDAU and SAU are only applicable for the Cortex-M33 as a master, but to protect Flash or SRAM from other masters, you need to configure the gates in front of the respective target. On figure 9.4 you can see how IDAU and SAU are only relevant for the Cortex-M33 core.

System Security in STM32L5

Figure 9.4: System Security in STM32L5

The importance of security on system level was already mentioned in chapter 5.7: On a system on a chip, the processing unit is only one actor in a complex system, the actors beeing interconnected on a bus system. In the STM32L5 there are 3 masters - two additional to the Cortex-M33 - which can issue transations on the bus and access peripherals, flash or SRAM. These are the DMA controller and the SDMMC controller. In the STM32L5 the security status of transactions issued by these masters are not filtered through IDAU and SAU configuration:

The SAU/IDAU settings are applicable to only the Cortex-M33. The other masters like DMA are not affected by those policies. [5]

To filter these transations either a security gate is added in front of the slaves or the slaves themselves are TrustZone-aware. When transactions from Cortex-M33 are initiated, this results in a transaction beeing filtered twice:

  1. IDAU / SAU
  2. by security gate or by TrustZone-aware peripheral itself

Other transactions, for example initiated by DMA master, are only filtered by the security gate in front of the slave.

The security gates in STM32L5 are configured through registes in the TrustZone security controller (TZSC). In STM32L5 the following peripherals have a security gate in front of them:

  • SRAM
  • peripherals
  • External Memories
  • External SRAM

For STM32L5 the following slaves are TrustZone aware, which means they don’t have a dedicated security gate in front of them. This also means, that they are not configured in the logical block of the GTZC, but in dedicated registers in the realm of the respective peripheral.

  • Flash
  • DMA
  • Cortex-M33
  • On-the-fly encryption/decryption (OTFDEC)
  • Power Control (PWR), Secure clock and reset (RCC), Real time clock (RTC)
  • Tamper and backup registers (TAMP)
  • General-purpose I/Os (GPIO)
  • Extended interrupts and event controller (EXTI)
  • System configuration controller (SYSCFG)

The naming of the configuration registers follows their logical location: The SRAM for example has a block-based security gate in front. Since all security gates are part of the GTZC, the register to configure the SRAM security gate is named GTZC_MPCBB_* (it is a block-based memory protection gate). The flash on the other side is itself TrustZone-aware, so it’s security configuration registers are prefixed with FLASH_*.

Table 9.3: Naming Logic of configuration registers
Component Security configuration register names
SAU SAU_* - Part of Cortex-M33
SRAM GTZC_MPCBB_* (non-aware, configured in TZSC, which is part of GTZC)
Peripherals (not aware) GTZC_TZSC_*
Peripherals(TZ aware) Configured in eachs space, eg for RCC: RCC_*.
Flash FLASH_* (TrustZone-aware)

STM32L5 implements a Global TrustZone controller (GTZC), with the following sub-blocks:

  • TrustZone security controller (TZSC): Chapter 9.5.1
  • TrustZone illegal access controller (TZIC): Chapter 9.5.2
  • SRAM security configuration (block-based security gate, MPCBB): 9.5.3

Since Flash itself is TrustZone aware it does not logically belong to the GTZC. The security configurations for Flash are highly relevant for overall system security, so it does make sense to describe them in the current chapter:

  • Flash security configuration (watermark-based security gate): Chapter 9.5.4

More on System Security Components:

  • Chapter 5.7.1: System Security Controller
  • Chapter 5.7.2: Security wrapper
  • Chapter 5.7.3: Block-based Gate
  • Chapter 5.7.4: Watermark-based Gate
  • Chapter 5.7.5: Select-based Gate
  • Chapter 5.7.6: Lite-IDAU
  • Chapter 9.5.2: STM32L5: TrustZone Illegal Access Controller (TZIC)
  • Chapter 10.2.2: Example STM32L5: GTZC Configuration (Example 1)

More on System Security Design:

  • Chapter 5.7: System Design: Security Gates and System Security Controllers
  • Chapter 9.5.2: STM32L5: TrustZone Illegal Access Controller (TZIC)

TrustZone security controller (TZSC)

The TZSC is the component on STM32L5 which configures the secure and privilege state of slave and masters on the bus, e.g. whether the slave is only available in secure and/or privileged state. This is done by configuring the different gates,- which are in front of TrustZone unaware peripherals (like the watermark based gate) but also the security wrappers, which are in front of masters to correctly attribute transactions issued by non-TrustZone aware masters. (see chapter 5.7.2).

You can find more details on the TZSC in chapter 9.5.1.

TrustZone illegal access controller (TZIC)

The STM25L5 has 109 interrupts configured, plus the ARMv8-M default execeptions. One of these 109 interrupts is the GTZC interrupt at position 8. This interrupt is raised by TZIC, if an illegal access event has been reported to it by any gate. The TZIC concentrates all illegal access events. To determine which gate caused the illegal access event, developers can check registers in TZIC in the GTZC IRQ.

You can find more details on the TZIC in chapter 9.5.2.

9.5.1 TrustZone Security Controller (TZSC)

More on Arm Privilege Levels:

  • Chapter 5.2: Execution Modes and Privilege Levels (with TrustZone)
  • Chapter 4.4: Arm Architecture: Execution Modes and Privilege Levels

The sub-block TrustZone Security Controller (TZSC) defines the security level of slave and master peripherals to secure or non-secure state but also to privileged or unprivileged. These settings are done in the following registers:

  • GTZC_TZSC_SECCFGRx: Holds 1 bit per peripheral, which represents its security state (Secure or Non-Secure access). Reset value: 0x0000 0000, which is non-secure.
  • GTZC_TZSC_PRIVCFGRx: Holds 1 bit per peripheral, which represents its privilege state (privilege or non-privileged access). Reset value: 0x0000 0000, which is non-privileged.

Where x ={1,2} STM32CubeL5 HAL for TZSC

If you use the STM32CubeMX code generator to ramp up you project, you will find the necessary code to initialize GTZC in the function MX_GTZC_Init(void) in main.c. For TZSC it uses - depending on your configuration- the following HAL API functions:

  • HAL_GTZC_TZSC_ConfigPeriphAttributes(), HAL_GTZC_TZSC_GetConfigPeriphAttributes() to configure the peripherals you configured as secure and or privileged. This HAL functions set up the registers GTZC_TZSC_SECCFGRx and GTZC_TZSC_PRIVCFGRx accordingly.

  • HAL_GTZC_TZSC_Lock() / HAL_GTZC_TZSC_GetLock() to lock TZSC against modifications (until complete reset of TZSC). This HAL functions set up the GTZC_TZSC control register (GTZC_TZSC_CR) accordingly.


  • GTZC initialization in Example 1: Chapter 10.2.2

9.5.2 TrustZone Illegal Access Controller (TZIC)

See chapter 10.2.2 and chapter 10.2.4 for a example implementation, which uses STM32 HAL and the implemented GTZC TZIC callback to check an illegal access event.

TrustZone-aware peripherals and security gates report illegal access events to the TZIC. The TZIC then generates an interrupt (GTZC_IRQn) towards the NVIC. Illegal access events reported to TZIC can be:

  • illegal non-secure access: a non-secure transaction trying to access a secure component
  • illegal secure access:
    • a secure transaction trying to access non-secure SRAM, as defined by the block-based firewall.
    • a secure transaction trying to access non-secure watermark-based firewall protected external memories

The TZIC generates one interrupt for different events. To find out which event triggered the interrupt, TZIC provides different registers to filter. TZIC also provides means to mask events and thus disable generation of GTZC_IRQn per event.

  • GTZC_TZIC_IERn: The GTZC_TZIC Interrupt Enable Register is used to mask individual events generating GTZC_IRQs towards the NVIC. Default: All events are masked.
  • GTZC_TZIC_SRn: The GTZC_TZIC Status Register is used to show which source created the illegal access. There is a flag for each peripheral.
  • GTZC_TZIC_FCRn: The GTZC_TZIC Clear Register is used to clear the flags set in GTZC_TZIC_SRn.

Where n = {1,2,3}.

More on Arm Exception System:

  • Chapter 4.6.2: Arm Architecture:NVIC
  • Chapter 4.6.3: Arm Architecture: Masking
  • Chapter 7.3: Exception Entry and Return
  • Chapter 9.5.2: STM32L5: TrustZone Illegal Access Controller (TZIC)
  • Chapter 4.4: Arm Architecture: Execution Modes and Privilege Levels
  • Chapter 4.6: Arm Architecture:Exceptions, Interrupts, Faults
  • Chapter 8.5: Secure and non-secure exceptions

More on Interrupts:

  • Chapter 4.6.2: Arm Architecture:NVIC
  • Chapter 4.6.3: Arm Architecture: Masking

SAU and IDAU are located in the core block and thus don’t report illegal events to TZIC. Violations of the SAU/IDAU security policy are reported directly to the core using a SecureFault exception. Sidenote: Armv8-M cores without the main extension (base only), don’t have a SecureFault and use a HardFault exception. For more details see the next level box above. STM32 HAL for TZIC

  • HAL_GTZC_TZIC_DisableIT() / HAL_GTZC_TZIC_EnableIT() to mask / unmask the reporting of illegal access event for peripherals, which are configured to report their illegal access events to the TZIC.

  • HAL_GTZC_TZIC_GetFlag() / HAL_GTZC_TZIC_ClearFlag() to control flags in GTZC_TZIC_SRn and GTZC_TZIC_FCRn.

  • There is a default interrupt handler for GTZC_IRQn implemented, which is named HAL_GTZC_IRQHandler(). Developers can can add own code using HAL_GTZC_TZIC_Callback()


  • TZIC configuration in Example 1: Chapter 10.2.2

9.5.3 SRAM

The STM32L552x has up to 256 Kbytes of internal SRAM:

  • 192 KBytes of SRAM1
  • 64 Kbytes of SRAM2

There are different security options available on STM32L552x:

  • When TrustZone is enabled, SRAM2 can be write protected on a 1 KByte granularity.
  • When Read Out Protection is enabled (see 9.2.1), SRAM is also protected.
  • When TrustZone is enabled, SRAM is attributed secure by default and can be reattributed to non-secure on a 256 byte sized granularity through the block-based memory protection controller.

Write Protection is configured in SYSCFG (System Configuration Controller) block. The respective registers are:


If TrustZone is not enabled, there is no access restriction.

SRAM is not TrustZone-aware and thus has a block-based gate in front of it. Actually, there are two MPCBB (block-based memory protection controller) blocks: MPCBB1 is in front of SRAM1 and MPCBB2 in front of SRAM2. According to the logic determined in table 9.3 the respective configuration registers are located in GTZC and named accordingly:


Where x is 1 or 2 (for MPCBB1 and MPCBB2) and y is a register of 32 bit. There registers are reset to 0xFFFF FFFF, so whole SRAM is secure (when TrustZone is enabled). Security configuration of MPCBB can also be locked using the registers GTZC_MPCBBx_LCKVTRy.

More on SRAM Protections:

  • Chapter 5.7: System Design: Security Gates and System Security Controllers
  • Chapter 9.5.3: STM32L5: SRAM STM32 HAL for SRAM Security Configuration

  • The HAL provides multiple functions to configure SRAM MPCBB1 and 2: HAL_GTZC_MPCBB_ConfigMem() and HAL_GTZC_MPCBB_ConfigMemAttributes()
  • To configure the lock or get the lock status: HAL_GTZC_MPCBB_Lock() and HAL_GTZC_MPCBB_GetLock().

9.5.4 Flash

The internal Flash can be divided into main block and an information block. The information block is used to store configuration, ST propierary code and OTP data. Only parts of the information can be modified by the user, other parts are reserved for STM. The information block is also used to store the option bytes. See chapter 10.2.1 for an example option byte configuration.

The main block can be run into 1 or 2 banks (dual bank mode, DBANK=1 option byte). Dual bank mode offers the possibility to read on one bank, while executing on the other (Read-while-write (RWW)). The page size differ in each mode:

  • DBANK=0: page size is 4 KByte
  • DBANK=1: page size is 2 KByte

STM32L552x brings multiple protection mechanisms for flash memory:

  • Write Protection (WRP):
    • DBANK=0: 4 areas, page granularity
    • DBANK=1: 2 areas per bank, page granularity
  • Readout Protection (RDP)

When TrustZone is enabled, Flash can be further protected by:

  • Secure watermark-based area (SECWM): Protection against non-secure read and write access. This is the state Flash is in per-default, when TrustZone is enabled.

    • DBANK=0: 2 areas, page granularity
    • DBANK=1: 1 per bank, page granularity
  • Secure block-based area (SECBB): Flash pages can be programmed on-the-fly as “secure”, when they are marked as nonsecure in SECWM.

  • Secure hide protection (HDP): Parts of SECWM regions can be further protected by hiding them until the next reset. When HDP protections for a region is enabled, read, write and fetch is denied for that region.

    • DBANK=0: 2 areas, page granularity
    • DBANK=1: 1 area per bank, page granularity

More on Flash Protections:

  • Chapter 5.7: System Design: Security Gates and System Security Controllers
  • Chapter 9.5.4: STM32L5: Flash

Write Protection (WRP) is configured in the option bytes FLASH_WRP1AR, FLASH_WRP1BR, FLASH_WRP2AR, FLASH_WRP2BR. The areas protected against write operations are configured relative to the flash base address. Details can be found in [5, p. 201].

Depending on the RDP level (0, 1 or 2) different protections are applied to flash. The default level is 0, which has no protections. See 9.2.1 for details on flash protections in each level. Additional details are available in [5, p. 203].

When TrustZone is active flash memory can further be protected against non-secure read and write access. There are two secure areas the developer can define in the option bytes. The areas are defined by a start and end page offset. This Secure watermark-based area (SECWM) is configured in the option bytes register FLASH_SECWMnR1 where n = {1,2}. These 2 registers contain different option bytes, where the start and end page offsets can be set:


See chapter 10.2.1 for an example on SECWM_* configuration.

Watermarked areas can further be protected by Hide Protection (HDP). If a watermarked area in flash is further protected by hide protections, read, write and fetch on this area is denied until the next device reset. HDP is configured in FLASH_SECWMnR2 where n = {1,2}. These two registers contain two option bytes:

  • HDPnEN

If HDPnEN = 1 and SECWMn_PSTRT <= HDPn_PEND <= SECWMn_PEND the area between SECWMn_PSTRT and HDPn_PEND is hide protected.

Additionally to the configuration in FLASH_SECWMnR2, the bit HDPn_ACCDIS in flash register FLASH_SECHDPCR must be enabled, to deny access to the respective HDP area. This register is not loaded from flash and used to enable HDP by the developer.

Watermark and Hide Protected Area in STM32L5

Figure 9.5: Watermark and Hide Protected Area in STM32L5 STM32 HAL for Flash Security Configuration

STM32 HAL provides functions to program the protection mechanisms through HAL.

  • HAL_FLASHEx_OBProgram (FLASH_OBProgramInitTypeDef * pOBInit) can be used to program option bytes. FLASH_OBProgramInitTypeDef is a struct which holds fields for all the fields to configure all protections mentioned in the chapter above, including the watermark and hide protected areas.

  • HAL_FLASHEx_EnableSecHideProtection() can be used to configure HDPn_ACCDIS in FLASH_SECHDPCR.

11 Flexible static memory controller


[5] ST Microelectronics, “Reference Manual.” 2020, [Online]. Available:

[8] ST Microelectronics, “Getting started with STM32L5 Series microcontrollers and TrustZone development.” 2020, [Online]. Available:

  1. fn-cv-stm32-1↩︎

  2. fn-cv-stm32-1↩︎