 Hello, it's Bob Waskowitz from ST Microelectronics, staff engineer, back with part six of our nine-part video series on the STM32L5 trust zone. In part six, we're going to take a non-secure application and add it to the trusted application, which we did in hands-on number two. This brings us to hands-on number three. So we're going to expand on hands-on number two, and this time the secure application is going to make the jump to the non-secure and call a non-secure, adding a second LED blinking, the blue one, at a one-second rate. So hands-on number three came from the GPIO toggle trust zone. A secure, non-secure setup is a dual project, and I have a couple slides down the road here to talk about that. So as mentioned, secure is going to blink the green, non-secure is going to blink the blue. So once again, IAR 8.40.2 was used to compile the hex files that you have. The secure linking project will now configure the secure application, so it's going to release the GPIO that's needed to blink, for the blue LED to blink, and the non-secure blinking project will be configured as a non-secure project within this dual project of IAR. And we mentioned about this non-secure callable API, so the secure has to release the GPIO. There are secure faults, which are passed back and forth. So this secure.nsc non-secure callable library is generated when you generate the secure project, and it's linked in to the non-secure project. So I'll show you that in a few slides with the IAR. The physical location of these projects, so one's going to start the secure project at the beginning of Bank 1, which is the C00000, and then if you remember the secure, the non-secure Bank 2 starts at 8040000, and I'll show you that in the linker file as the way they're set up. Reminder slide, you've seen this before when we were doing the secure project. So basically Flash 1 and 2 set up for secure non-secure SRAM 1, SRAM 2 set up for secure by the SAU, and then the SAU Global Trust Zone Controller, we're really not using any peripherals that are controlled by that since the GPIO is trust zone aware, so we don't have to, but if we were using a UR or a SPI or something, then we'd have to set the Global Trust Zone Controller up. The trust zone has been enabled. We've configured the secure memory 1 watermark and the secure memory 2 watermark, so nothing to do here, just a reminder. Once again, another reminder that how the secure watermark should be configured if the start address is greater than the end address than that whole bank is, but if you need to carve out certain, if you need more memory, more Flash, then you can set up particular sectors to do what you want to do. So here are the two slides coming up that I talked about, the flow of developing secure and non-secure applications. Each application is generated independently of the other. The secure project exports this NCS live file, which is the gateway, this NCS callable from the secure to the non-secure. The non-secure is linked against that secure gateway library. So the build order is very important when you look at the examples within the how. You need to build the secure project first, then you build the non-secure project. So the tool chain IDE compiler, whether it's IAR Kyle or the CUBE IDE, needs to be aware of the secure side. So there's a bit that we're going to set, and we're going to determine which one is secure, which one is non-secure, as you've seen. The language extensions are important as far as the API going back and forth, and the extra instructions for the different states of the core need to be made aware of. From a non-secure project side, you can develop that. That's just like developing its own application, and you can figure it the way you normally would with the allocation of peripherals and stuff in the normal how, and can be debugged and checked out individually. However, where it's linked to the memory addressing, you do need to be aware of where you're locating it, and I'll show you that in the tool chain configuration slides. So again, we're going to talk a little bit about the flow and the modifications of the main. I'm not going through the sysinit and startup, the SAU, all that stays the same. We just said the global trust zone controller. We're not configuring that because the peripherals we're using don't need to be configured. So I'm just going to talk a little bit about those commented out sections that you previously saw. So we need to tell the non-secure side which IO is available. So we're going to uncomment that section out for this secure side, which we see. And then also, we're going to allocate everything except for the green LED port pin to the non-secure side. A little extreme, but this makes all the GPIO available then on the non-secure side. Once we release the GPIO, the next modification is to allow the jump to occur from the secure side to the non-secure side. This is the non-secure init, and you'll see that the jump is actually to vTor table underscore non-secure start address. And that physical address is listed up in the defines as 804,000, and that's the start. So if you're changing the memory, if you're changing the flash location of this, if you're reallocating more than half and half, three quarters, one quarter, this is the area that you would change. In addition to this, there's also this output file that's created, and I'll show you that in the IAR configuration, which is that non-secure live output. And that's the link that, so the non-secure project will have to link this in to make it aware of what IO is non-secure and going back and forth between the two regions for the faults as well. So if we look at the IAR configuration, we've got the trust zone enabled, make it aware. This is the secure project for the trust zone. If we look at the linker file, it's going to be the same as the previous hands-on example. We're locating the secure code in Bank 1, which is at C00000. Same for the flash ROM, we're using the whole bank for that. And the SRAM is going to be at 300,000. The output of the secure nsclib.a binary is what's new. So if I look at the linker, this file is output from the secure project, and this file will be linked in to the non-secure project. So what are we doing from the non-secure side? Again, the same color coding. Blue is normal, and red means I made some changes. So we start out with the same sysinit call from the secure side. The pound defined for the vector table offset is commented out, so that's not doing anything. So the sysinit on the non-secure side does nothing. So what's the first thing that gets done in the main of the non-secure? Well, there's two callbacks set up. One is the secure fault, and the other one is the global trust zone controller error. Remember that GZTC also controls interrupt vector interrupts, which the sys-tick would be using to do this from the non-secure side to the secure side. We get the same warning in the non-secure side about the sys-tick and the time bases and having multiple time bases, and then the halinit sets up the sys-tick. So in this case, we do have two separate sys-ticks. We have the one on the secure side and the one on the non-secure side, both doing their own independent thing. So the next configuration is the system clock. This was also configured on the secure side up to 110 MHz, and the APBs were all configured as well. Unless you're redefining them, there's nothing that's going to happen there. And then we're going to go to the GPIO-NIT. We have to enable the pins for the blue LED, and we'll talk a little bit about that next. So remember there are three LEDs on the board. We're using the green one for the secure that leaves the red and the blue not being used. We allocated all the GPIO other than the green LED to the non-secure side. So in this example right now, we're turning on the clocks for the red and the blue LED. However, we're only using the blue LED. So the non-secure side is going to wind up in a while loop for the main, in which case the SysTick interrupt is then going to determine the blink rate of the blue LED. And in this case, the SysTick callback is set up for 500 milliseconds. So the blue LED is going to blink twice as fast as the green LED is what you're going to see. So on the non-secure side, there is an error handler callback. And right now, out of the box, that's set up to turn on the blue LED solid if it were to happen. However, the while loop has nothing in it. The SysTick is just basically doing its thing, generating an interrupt. So if you want to go into the Cube L5 GPIO toggle trust zone example, you could add a LED toggle from the non-secure side and try to toggle that green LED on the secure side. You would generate a secure fault, which would generate the global trust zone controller would generate this error handler. And then that's how you would eventually like it, like this. I didn't get, we didn't have enough time in the two hours to do all this. So that may be left up to you to maybe try as the next step. So what do we configure in the IDE to let it know that this is a non-secure application? The trust zone is enabled and now we have the non-secure mode checked. Okay, so where is the linker placing this non-secure application? Well, as previously discussed, the jump on the secure side is going to be the 804,000. So that's where the vector table is going to be. The memory, the flash is going to be there as well because it's in flash. And then, of course, the SRAM is going to be at the 200,000 range because that's where the non-secure SRAM is. And remember, there was 192K allocated for secure and the other 64K, I think it was, was allocated for non-secure. And then finally, the non-secure file needs to know where to get that secure underscore ncflib.afile that was created by the secure project. And that's an input then to this non-secure project. This brings us to the actual downloading of the hex files and seeing if they both work, which hopefully they should. So once again, we're going to connect the cube programmer to the stlink on the nuclear board. So the first thing I need you to do is let the default stlink stay as it is, hit the connect button as we've done twice before. This is going to give you some information, which is telling you that you successfully connected to the nuclear board. We're going to open the hands-on number 39 secure file first. I want you to disregard this blue tab you see. I forgot, as I told you all, in the end of handle number two to close that. So this is left over from before. So what I want you to do is hit the plus, you should have the plus tab there, and then select open file and browse to where you've located the hex files and pick the hands-on underscore three underscore ns non-secure.hex file. Go ahead and load it. You'll see the new tab created. Note that the load address is 804,000, because that's what we just talked about. Next we're going to load the secure jump file. So again, we're going to hit the open file where the plus tab, and we're going to browse to the same folder, and we're going to select the hands-on underscore three s for secure jump hex file. We're going to see a new tab open up, and we're going to see the load address of that file is at C00000, just as we saw on hands-on number two. We still have the previous hands-on number two on the board, so we're going to erase that flash from the secure side. So we're going to select the download icon, and we're going to do a full chip erase selected just as we did previous. You're going to OK. Are you sure you want to erase it? And you're going to hit OK. And then you're going to note the mass erase successfully was achieved. All right. Now we're going to program the two files. Remember, the option blades have already been set, so we have everything ready to go. Bank one is secure, bank two is non-secure. The SAU is set up for the SRAM. We're good, right? So we're going to go back to the Select the File Editor icon. We're going to load the non-secure first because it's going to just sit there and act, right? Because the way the trust zone boots is it's going to boot basically from secure first. So go ahead and make active the hands-on three non-secure hex file. Again, go over to the Download tab. Don't select the pull-down options. OK the file download, and you'll see the information in your log window. These next two steps, 5A and 5B, have a little bit of a story behind it. So I want to show you the pull-downs on that Download button that we've been using to download the files. So go over to the Download pull-down, and you're going to see some options for different things. One of those options is Verify, and then you're going to see a grayed-out address which is basically the load address of the hex file. And then I want you to select that. And if you've got a successful download from the previous step, all things should verify. And then you acknowledge the verification successfully tab. If you ever get a mismatch, obviously the goal would then be to repeat the download. So in preparation for this hands-on, the original intent was to use version 2.4 of the Q programmer. Well, we discovered a little bug in 2.4. So when downloading the non-secure file, there's something going on with the SAU configuration. So checking with the division, we realize that there was an error there. They are going to fix the error. They will be fixed in version 2.5. So that's why we're using version 2.3, which brings me to slide 5B. So we're going to re-download again, and if things work, then they're good. So by the SAU having its issue, what would happen would be is one out of two or three times the non-secure download would actually fail. And remember that RAS, read as zeros, you would get that. That's how I knew there was something wrong with the SAU configuration. So I wanted to throw that in here. Again, version 2.4 works for other things, but we did find that bug, so we're using version 2.3. And there will be a new release of the Q programmer coming in June with version 2.5. So again, you would okay the file download message, and then you would continue. But hopefully nobody has any problems. If you do have a problem, repeat these steps. With the non-secure downloaded, we need to download the secure file. So we're going to make the hands-on 3 underscore s jump file, the active file. We're going to select the download, but don't do the pulldowns. And we're going to okay the file download. And we're going to note the long window that the download was complete. So once again, some cleanup operations before we actually run the code. We're going to disconnect the Q programmer from the ST link. And we're going to see that the disconnect happens. And then we're going to close the open files by clicking on the X for each of them. Then we're going to run the application. So all that's needed to do is press the reset button. And LED 1, the green shall blink at the previous 2 second rate. And then you'll see the blue LED blinking concurrently next to it, which is coming from the non-secure application. This concludes hands-on number 3. So we downloaded a secure. We downloaded non-secure, the one called the other. The application left to you guys, the attendees, is to maybe go in and add an extra line to the non-secure side. Try to toggle the green LED on the secure side. And things should be set up so that you'll get the error and the blue LED will stay lit. You can change that blue LED to the red LED by reconfiguring it to the PA5, as I suggested previously. Thank you for taking the effort to execute Part 6, our hands-on number 3 of the nine-part video series on the STM32 L5 trust zone. I invite you to continue with Part 7, which is hands-on number 4, which will now show you how to set up the IAR IDE to concurrently debug, go back and forth between the non-secure and the secure, and see some of the symbol data that will be necessary when you're putting these types of applications together.