 Hello again. I'm Bob Waskiewicz from ST Microelectronics, staff engineer. Back at you with part three of our nine part video series on the STM32L5 trust zone. In part three, we're going to introduce the ARM trust zone concept from ARM's perspective. They've been around for a while. ARM has been supplying them with their Cortex A&P used for many years. They are new to the Cortex M series, the Micro series. Conceptually, the ideas between the two are the same. Operationally, they're much different. As mentioned previously, the trust zone is an option within the M33 core. All STM32L5s contain the trust zone. When you enable the trust zone, the boot state is the secure state. When the trust zone is disabled, as we did in hands on one, the L5 acts like a normal MCU. Unlike the Cortex A trust zone, the M33 trust zone is memory mapped. The transitions between the secure and the non-secure sections can happen from multiple points, which makes it robust for an embedded system. The Cortex A trust zone had a secure monitor exception handler in it that all transitions must go through. However, the A's are running at a higher frequency than the M's are, so part of the reason for doing so is because of this frequency limitation. When the TZN bit is set, this is how the device comes up in the secure state. All the memory and the peripherals can be accessed. The system control and debug area provides access to the secure peripherals and the non-secure peripherals are mirrored at memory alias addresses, which I'll get to in a few slides after hands on number two. The secure peripherals are only accessible when the device is in a secure state. We have this piece of IP internally called the secure attribution unit, and this will configure the peripherals for access. As you can see, there's duplicates of the memory protection unit, of the SRAM addressing, and all that is set up by the secure attribution unit, which we'll talk about in a few slides. This is what the memory map looks like from the non-secure side. Any access to secure memory or peripheral will trigger a security exception, which is a new exception handler to the L5. Code that is executed from a non-secure region is executed in a non-secure state and can only access the non-secure memory region. So we're going to get into this aliasing memory map in a few slides, but this is how it works. So this is the ARM architecture of the M33. What I wanted to highlight over the next couple slides are these new sections that actually do the controlling of the secure and the non-secure, and this is basically the SAU and the IDAU, which we'll talk about on the next slide. First thing I need to say is that the SAU and the IDAU only come into play when the trust zone is enabled. In the legacy mode, none of this has to be configured. It runs just like a normal MCU. The IDAU, which stands for the Implementation Defined Attribution Unit, think of it as a hardware configuration coexisting with the SAU, Security Attribution Unit, which is where the software allows you to reconfigure the system within limits. There have been certain regions selected that can do certain things, but it does allow the user to define them. In addition to the SAU and the IDAU, then there's also unique memory protection units for the secure and the non-secure sections, regions. So these two can have other layers of security protection as well. A little deeper into the SAU and the IDAU. When we say ARM allows the SAU to be configured, this is the VHDL level. So the STM32L5 is built so that the SAU has eight regions, gives us the most diversity. There are two states now when the trust zone is enabled, secure and then non-secure. One of the differences I highlighted between the Cortex-A trust zone and the M trust zone was the fact that the M can branch directly because of this direct memory mapping. So the IDAU is what limits where things go with the help of the SAU. Because remember, the IDAU is configured as a default. If you don't do anything, you get this, but then you can override it with the SAU. And there's two memory types. Secure, of course, meaning I'm on the secure side. I can see the whole world as I showed you previously on the table. This non-secure callable is an intermediate call from the secure into the non-secure. And then, of course, there's a non-secure, which means it can't access anything but the non-secure. And we'll get into what these are on the next slide. So this is what the software flow looks like between the non-secure and the secure. When the non-secure wants to call a secure world, it has to go through the non-secure callable region. This contains all the entry points into the secure world. If the non-secure tries to jump directly to the secure world, a security fault is generated. When the secure world returns to the non-secure world, it's direct. It doesn't have to go through the non-secure callable. So the non-secure callable contains all the entry points of the secure world. And when the CPU is in a non-secure state, there is no way for it to jump directly into the secure world. I want to thank you for watching part three of the nine-part video series on the STM32L5 trust zone. I encourage you to continue with part four, hands-on number two, in which we activate the trust zone within the STM32L5 on the nuclear board.