 Hello, everyone. Bob Wasquitz from ST Microelectronics, staff engineer, here with part 7 of our 9-part video series on the STM32L5 trust zone. This part was not originally included in the webinar on the STM32L5 virtual hands-on back in May. As I've gone through questions coming back from the webinar, we started with hex files and used a Q-programmer to download these hex files. We never really got into debugging the actual secure and non-secure applications. So the next couple of slides, some of them are redundant. We've already done this in the slides leading up to the non-secure and secure applications. But I'm going to show you what you need to do in order to include the non-secure image with the secure image for debugging so that you can put breakpoints as you're going back and forth from secure to non-secure, non-secure to secure through the non-secure callable library as well. Setup slide one of five pertains to the secure project. The first two steps I've showed you on previous hands-on, basically hands-on number two when we were doing the secure application setup. What I didn't show you was the optimization change. When optimizations are used, the buggers have combined instructions on the same line, so not all breakpoints are shown or are available. So for the simplicity of debugging and as a practice I do all the time, I always turn optimizations off. So when configuring the secure project, you want to go in, you know, under the CC++ compiler and change optimizations from typically high, which is what are in our HAL examples, or which come out of the QMX configuration to none. We're still configuring the secure project and these first two steps were previously shown to you in the non-secure hands-on. I have a note there that sometimes the file names change, which I did for this particular slide set. What's very important is the next step, which is basically including the debug information from the non-secure side. And then what I'll also show you, which is important later on, is the sequence in which you debug. Basically, you load the non-secure first and then you're going to load this secure image with the link to the debug information from the non-secure side. This will then allow you to see and operate breakpoints and stop, you know, through one workspace under IAR. When configuring the non-secure application, again, the first step was shown through the IDE. I'm just going to mention again, when configuring optimizations, make sure you go from high optimization to none to be sure that the IDE, where the compiler gets all the information into the debug file. Again, the first step here is redundant. This is the step which allows the library from the generated, from the secure application for the non-secure callables to be done. When it comes time to build the project, and I mentioned this briefly before, but you need to build the secure side first, so that the output library for the non-secure callable is generated, and then build the non-secure project second in order to link in the output. Okay, we're almost ready to debug, so you're going to go and you're going to download the non-secure image first, then you're going to download the secure image, which has the additional information for the symbol data. In the editor under IAR, you're going to split the editor into two, so that as you open files from the secure project, you're going to see them in one editor, and you're going to see the non-secure files in the other side of the editor. So this makes it easy to follow while you're debugging. Note that there are some similar files between the two projects, in which case they're going to be either in one or the other, but not both when you're debugging. Okay, so if you don't include the image for the secure side, what's going to happen is if you try to actually put breakpoints on the non-secure side, of course it doesn't have them, so you're not going to be able to do it. So this here first result shows you what happens when you configure things wrong. When you have the configuration right with that additional image on the debug side of the secure project, you can break as you're coming through the startup code on the secure application. You can then jump to the non-secure side, and then you will see the to break, and you can look at the disassembly and the disassembly window as well. Now this result three I'm putting in here just to show you that you can also trace from going from the non-secure side to the secure side. In the hands-on I alluded to actually adding a secure call from the non-secure side, which can happen. It will then go through the non-secure callable, but without that additional image it's not going to hit the breakpoints. So although the example you have does not have this capability, just be aware that you can do this as well. This is just to show you a continuation of the previous slide in which case on the non-secure side you're making the call to a secure toggle and on the other secure side you're going to call it to the non-secure toggle. But regardless, you can see the breakpoints work when you have to configure properly, and then at the bottom I show you the non-secure callable library, which is output from the secure side. You will also be able to break into that code as well. Thank you once again for spending time with Part 7. Not really a hands-on, more of a showing how to, because we never really use the source code when creating the hands-ons for the secure and the non-secure. This will give you an idea of what needs to be done. It came out of as many questions that I would ask from the previous release of this video series. So I encourage you to continue with the last two parts, number eight and nine, in which case we'll get into the flash enhancement and the deactivation of the trust zone.