 Hello again. I'm Bob Waskowitz with ST Microelectronics, staff engineer with part four of our nine-part video series on the STM32L5 trust zone. In part three, we introduced the ARM trust zones concept. Part four, hands-on number two, we will activate the trust zone on the STM32L5. Handle number two, the first thing we're going to do is enable the trust zone. Then we're going to download a secure only application. There's no call to a non-secure application. We're going to examine the flow of how to set up the secure application up to the jump, which we're not going to make. There's three LEDs on the nuclear board. My intent was to use the green LED as the secure toggle. The blue LED is toggled by the non-secure and the red LED is the fault. However, we're not going to get to the red LED and that can be an additional hands-on that you might want to investigate on your own. So the hands-on number two source comes directly from the GPIO toggle trust zone example. And as I alluded to back when I was talking about the SAU and the IDAU and the flow, every trust zone example has two projects. There's a secure project. We'll go through that. And there's a non-secure project. We'll go through that. The toggle of the LED is controlled by the SISTIC callback. And it's a one millisecond. We have a delay. I think I put it in there for one second for each off and on. And we'll go through that. Again, IAR 8.40.2 was used to compile it. And we needed to flip the trust zone bit in the project setup, and I'll show you how all that's configured as well. So once we enable the trust zone, the IDAU configures everything as secure. So I talked about the SAU on the previous slides. There's also this GTZC, which is the global trust zone controller, which controls the peripheral secure versus non-secure configuration. Both of those are configured at startup. So the HAL has an assumption of how we want to use the memory within our library. And we configure the HAL configures Bank 1 as secure, Bank 2 as non-secure, SRAM Bank 1 as secure, and SRAM Bank 2 as non-secure. So you may want to have three quarters of the flash secure and one quarter of it non-secure. However you want to configure your project, it's totally up to you. This is how the HAL starts out. In my career with ST, I've done many hands-on seminars, two hours, four hours, eight hours, in the settings with rooms of people, and you all are physically there, and I can see. When it came time to do these virtual ones, I was trying to segment the hands-on so that it wasn't 50 minutes of slides, but it was some lecture slides that give you some theory on the architecture. But then we're also getting some lecture slides here on the configuration of what you're going to do in this hands-on number two. In addition, some of the stuff you do in hands-on number two we're going to learn about in the lecture slides of hands-on number three. So if you're learning to run before you can walk, that's a little bit true, but just bear with me. And then at the end, let me know how I did. So there's four things that need to be enabled to turn on the trust zone, and these are in the option bytes. The option bytes can be configured in the application or they're typically configured on the production line, and then the application is loaded into it. So the first bit that you have to set when you want to turn the trust zone on is the TZEN-enabled bit. The fault is zero, you make it a one. That has to be an independent step because once you enable the trust zone, other option bits which were hidden when the trust zone was disabled become visible. So we're going to set the trust zone enable. We also need to set the D bank to equal one. That's a default bank. That's actually what splits the flash memory into bank one and bank two. If you set that to a zero, make it one continual bank, then the whole device becomes trusted, and there's no real way to add any untrusted code to it. So we're going to set up a dual bank. One of the option bytes that becomes visible once you set the trust zone enable is what we're calling the bank secure watermarks. These are independent from the SAU, but they have to agree with the SAU and the IDAU. So this ALI thing that I'm going to get to in the next slide deck for handle number three, the non-secure region is 800,000 for flash, and the secure region is C000,000. And within that region, we have 256 banks, 256K banks of flash. So that's why bank one is either at 800,000 or C00,000 depending on whether it's secure or non-secure. And then bank two would be at 804,000 or C04,000 depending on whether it's secure or non-secure. The configuration of the secure watermark one and secure watermark two are done by creating a start sector and an end sector. However, if you want to do a complete bank that way, bank one is secure, bank two is non-secure, if the start sector is greater than the end sector, it automatically assumes that it's a totally secure bank. And that's what we're going to do when we configure ours. If you need to carve out a secure section of it for some reason, you can do that as long as the SAU is aware of it as well. You can configure it in any way that you want. But remember, the how, as mentioned previously, assumes that bank one is secure and bank two is non-secure. Next, we're going to go through the flow of setting up this secure project as I did in handle number one. Blue is going to mean that it's existing, it hasn't been changed. Red means there's modifications. Whether it's a secure project or a non-secure project, one of the first things that happens, not one of the first things that happens is there's a .s file that gets executed which sets up the heap in the stack and the vector table. And one of the very first calls jumps in that setup file is a call to system init. When system init is called, the very first thing is done from a secure project perspective. This will not be done in the non-secure project is the configuration of the SAU. I'm not going to go into the configuration. There's a whole set of registers and stuff. You can go ahead and look at the source code for these projects to show you what it is and use a reference manual to figure it out. But time doesn't allow it. But I'm just making you aware of this is how the SAU would be set up so that all the peripherals are secure. Bank 1 is secure. Bank 2 is unsecure. SRAM 1 is secure. SRAM 2 is non-secure. When the system init is complete, which sets up the SAU and some clocks and vectors tables if you have all sets, upon the return the jump then occurs to main. The first node in main is what I referred to back when I said that the watermarks and the SAU all have to be cohesive. They all have to be configured knowing what each other is doing. So this is just a reminder that, you know, make sure that the software is agreeable with the way the hardware configuration is also set up. Next we're setting up the secure fault handler. And in this project it's all secure. We don't have a non-secure side of it so we don't expect these. This same project is used as the base for hands-on number 3. So that's why it's currently in this project to define the secure fault handler. The next thing that happens is this common pertaining to the sys tick and then this how init where it actually sets up the time base. For those new to the cube how, there is a time base. It's a 500 microsecond tick. We keep it at a 1 millisecond update. Timeouts, timing, callbacks are all done at a 1 millisecond rate. If you refer back a few slides, one of the new features of the trust zone is there are two 24-bit sys tick counters now in the L5. One for the secure side, one for the non-secure side. So you need to be aware of how you're doing your time base. When the RTOS gets involved, that also has a time base and typically the sys tick then becomes slave to the RTOS' time base. So this is just a note reminding you that there are now dual sys tick timers and be aware of which one you're using for which state of the trust zone. Next, we're going to configure the system clock. This is where we pick our clock source. We run it through the PLL and we ramp it up to 110 megahertz. That's what this actual example is doing. Out of power and reset, the internal HSI 16 megahertz clock is chosen. Out of system init, the same 16 megahertz clock is chosen. So this is where it gets bumped up to the 110 megahertz. Referring back to a couple of slides ago, the SAU and the GZTC get configured based on what peripherals are secure and what peripherals are non-secure and setting it up. In this case, the only peripherals we're using are the GPIO, which we'll go into in the next slide. But if you were doing URs or SPI or I-squared C, then this would have to be modified to enable them to be non-secure because remember, everything is assumed to be secure. The reason that the GPIO is not configured under the GZTC we'll get into this in a few slides is because GPIO ports are already assumed to be trust zone-aware and I'll get into that term after the handle of number two. So trust me on that. What I did do on this secure project is I had to make a few additions. Remember, I was talking about three LEDs, the LED green one for the secure side, the red one for the era, and the blue one for the non-secure side. So we're using the same base, so the next go round I will enable and add some stuff to it for LED two and LED one. But I'm just enabling the clocks here, so this red box means I changed this. And what else I changed, you have to tell the secure side what is not secure from a GPIO perspective. So these are commented out right now and on the next example, when we actually add an unsecure side to it, we will uncomment these and let them be configured. But that's what's going on in this set of GPIO changes. Along those same lines of GPIO modifications, what the default program says is, I'm going to take the green LED and I'm going to allocate that to the secure side, and then I'm going to make the rest of the GPIO available to the non-secure side. Because this is a secure only project, this does not have to be done, so that's why these are commented out. We're basically just using the green LED, which we configured in the previous slide to toggle the green LED light. So we're almost at the end. You can see the while loop we're going to go into. If this were a secure non-secure project, this secure would be calling the non-secure side and we'll get into this jump on the hands-on number three. So for right now, I commented out because I just want to stay on the secure side. And if I were to leave this in with no flash over in Bank 1, this is going to jump, and of course there's nothing there, so you're going to get a hard fault. The last thing that I need to show you is the time base for the SysTick. So this is the callback for the SysTick. It's going to, you know, SysTick's going to go one millisecond, update, and the actual count value are 1,000, so once every second it'll toggle on or off, thus flashing at a two-second rate. So these are all the configurations from the application side. So once the application has been configured, now I'll show you what goes on from the compiler side. Well, the trust zone is enabled, so we need to let the compiler know that the trust zone is enabled, but we also need to let the compiler know that this is a secure project. So everything, all the flash is going to be secure, the SAU is set up for the peripherals to be secure, and we didn't release any of the GPIOs, so it's all secure, and there's no jump to the non-secure world. So where will this hex file be located? The linker file is going to give us that information in the IDE. If I look at the linker file, the vector table is going to be located at C00000, and back on a few slides ago, I shared you the start of the secure side with C00000, and we'll get into this a little bit more on hands-on three. I just need to show it now because it could run the application, but also the flash, where's that, and where's the RAM that we're going to use, right? So flash is either C00000 or 800000, the RAM is at 200000 or 300000, depending on whether it's secure. In this case, we see where the flash is, we see where the SRAM is. Now we're ready to actually do a hands-on and actually download the file and execute it. So just like hands-on number one, the first thing we need to do is select the communication port, which we know is the ST link. We're going to connect to that, and then we're going to get the same log-on messages that we did from the hands-on showing us that we're physically now connected between the Q programmer and the Nucleo board. So we need to load our hex file into the Q programmer. So we're going to go to open file or the plus tab. Since you closed out and we haven't restarted the Q programmer, you're going to see a plus there to add a file. I want you to browse to where you stored the files and open the hands-on underscore 2 underscore S for secure underscore no jump because I commented out the jump to the non-secure side. You're going to note that once you open the tab, you're going to see the flash load. And this time, when you note the load address, you're going to see it at C00000 as I showed you previously in the linker file setup. Next, we're going to go ahead and erase the existing LED flashing blinky non-secure application. So we want to select the download icon as we did previous. This time, we just want to select a full chip erase. We're not going to load the file in as we did last time. Remember, I had you do a second browse. So selecting this full chip erase will prompt you, are you sure? And you're going to say OK. And once you say OK, it's going to erase itself, and then the mass erase is going to occur. Next, we're going to enable the L5 trust zone. So I need you to select the OB option byte icon, which is then going to open another window showing you the option bytes configuration. And as I mentioned previously, we're just doing a few of the bytes, a few of the bits of the bytes. There's actually a lot in here. This is all referenced in the L5 reference manual, if you want to get more information on it. So I need you to expand the user configuration. And remember, there's four things that need to be set to enable the trust zone. The D bank, the trust zone enable bit, and then the secure watermarks for bank one and bank two. So in this case, the D bank is already selected for you because that's the fault how we do everything with the L5. If you look down on that page, you'll see that TZEN, TZEN bit hasn't been set. So I need you to toggle that bit, meaning that we're going to set it. Then you're going to select apply, and you're going to get some feedback saying that the option bytes successfully programmed. And once that happens, you're going to see the blue option byte screen change. So those two new areas that were displayed are the secure watermarks for flash bank one and bank two, which appeared on your screen. If you expand both of those, you'll see that from a default configuration, it assumes that the secure bank one starts at sector zero, goes up to 7F, and secure bank two starts at sector zero and goes up to 7F. So out of the box, it assumes that all the flash is secure. We're going to make a modification to that to actually enable bank two to be non-secure. We could have left both banks secure because this program that we're going to run is a totally secure program. But in order to not have to get into the option byte configuration for handle number three, we're going to go ahead now and we're going to configure bank two to be non-secure. So we're going to edit the secure watermarks for number two, and remember, well, number one is going to have secure bank no change to that. But for number two, the other way to change it to include the whole bank if you didn't know what it would be is to make the start address bigger than the end address. So the tool knows to do this. Nothing's happening in the STM32L5 to have to do this, but the tool is doing it. So once you change the start address to zero one, and you change the end address to zero zero, select apply, and then OK, the message coming back, which is going to tell you that the option bytes were changed, and we're good to go for this hands-on, and we're also good to go for the next hands-on as well. Option bytes have been programmed, secured watermarks have been programmed, we have an application that's going to program our SAU, the global trust zone controller, we're not using anything other than the GPIO. We don't have to do that. So we're ready to load our hands-on number two secure node jump file. So again, we're going to select the file editor icon, which is going to put us back into the actual hex file was loaded. We're just going to select download this time. We're not going to go flash it and erase it. We've already erased the flash before we set the option byte. This is another quick way of downloading it. Note that there's an arrow on the download. There's a pull-down feature, which we'll do later on. I'll show you how to use the verify. But right now we're just going to select the download feature, and you're going to select OK to acknowledge the file download complete message, and you're going to note that the file is downloaded and how much time it took. So we just downloaded the file to C00000. We're going to close the file so that we have a starting point for the next hands-on. So just like at the end of hands-on number one, we're going to disconnect from the nuclear board. We're going to look at the login window to see that we disconnected, and we're going to close the hands-on to hex file that was open to actually do the download. Okay, next all we need to do is run the application. So we're going to press the reset button, and voila! Just the LED one, the green, is going to blink two-second rate, so we said it was going to be on for one second, and toggle off for one second. This concludes the hands-on number two. Again, summarize what we did. We enabled the trust zone. We downloaded a secure only project. In the next lecture, we're going to talk about some of the features of the non-secure and secure side in details, and we're going to get into actually hands-on number three, loading a secure and a non-secure application. Thank you for attempting part four, hands-on number two. I encourage you to continue with the nine-part video series with part five, the introduction of the non-secure application.