 Compile and debug the TFM. The first step will be to do a flash mass eras of our target. Just to ensure we don't have those remaining versions of the secure application to and such kind of things. Let's eras the flash. Then we will launch QBID and we will import the TFM project inside QBID. For the importation we just select the correct folder which is tfm-4-ws and we will uncheck this folder and also the loader because we don't use the TFM loader sources or project. Then we will launch the compilation of the TFM-SBSFU boot and then the TFM-ApplyNonsecure. When we compile the Nonsecure there is a dependency in QBID that will launch the compilation of the secure. And this is the traces that is expected. So let's do this first. Don't forget your flash mass eras to prevent an issue. And then let's launch QBID. So file. Open project from file system. For the directory here we start it from stm-2-thqws-tfm QBID will have 501.3.0 Project Nuclear Application TFM for Workshop Okay. And keep this level. Just select. And here as you can see we propose to import many things. Please n-click on tfm-4-ws because it was just a folder that's containing the order. And n-click on the TFM loader because we don't use this application. We are using the loader that is inside a non-secure application. And then just click finish. If I switch to project view. Sorry. Here now you should have this. TFM-SBSFU TFM-Apply Which contains the TFM-Apply secure. And the TFM-Apply non-secure. So first I will launch the compilation of the TFM-SBSFU boot. So I select the project and I press the hammer. Just show you that in the middle where you find the embed crypto that is used for the cryptographic port. The MCU boot which is the open sources of this secure boot. And trusted port is only for TFM when it's needed but here not really used. Mainly the application is here and it was more the adaptation data here. Compilation is nearly finished. Let's check the status together. Pause the build because it just generated everything. The build is finished with 0 error, 0 warning. Perfect. So now I propose that we compile the API secure and the API non-secure. So in the order we should compile the API secure first then the API non-secure. And maybe you can remember why. The API secure will I will say propose some secure services to the non-secure application. So you need to first compile the secure application. But this service automatically by a QBID. If I compile the API non-secure, look at the console. First it builds the TFM API secure. So here again the middleware, the trusted firmware and the core. And it's where you will find really all those services and all the source of this. In the application part you will just have the adaptation to our platform and the acceleration when it was needed. The code to use the acceleration is here. But in our case it's deactivated. The embed crypto compilation as it's also used by the crypto services here. Okay. The binary is compiled. Okay. It jumped to the non-secure application. But if I click on TFM API secure just to check the console log. You can see in the pose build that there is the error signatures, the number image. It was signed and encrypted. So it will generate on the pose build a version encrypted and a version unencrypted of this. And of course both are signed. But we will see this after. Let's come back to our non-secure application. We faster as you can see non-secure have been compiled. And exactly the same thing. There is a pose build. There is an error set 2048 for the signature check. And there is also some encryption. The key of encryption is generating during the build. So that means it will be different from one to another one. So here we finish compilation and status is okay for all of them. Let's come back to the presentation. I got a question. Do you think we can use QBID to flash the generated binaries? In fact, as I just told you, it will be possible for the TFM SPSU. But for the TFM API secure and the TFM API non-secure, there have been signed. There have been encrypted. So we can't flash them directly because it was not the binary generated that we want to flash. But I will say the image plus signatures. So it's not possible. But we can take the binary from this folder because it was generated and then we can flash them. And for flashing them, I created some scripts. So this time I create independence scripts for each binary. So first we will launch or flash the non-secure binary, then the secure binary, then the SPSU. Then we will press the reset which should achieve to these traces, which is quite similar to the first hands-on we have done together. Let's do this. First I propose. So we'll come back. So compilation is okay. Maybe interesting just to have a look of the binary generation. So in cube V1.3 and the project and the nuclear application, TFM for workshop and it was in the TFM app. If I will remember binary. Here you've got the generated binaries. So you've got the non-secure encrypted sign, the non-secure sign, not encrypted version of the non-secure application on the same for the secure. So now I will come back to the script. And I will flash my different binary. So first I will flash the non-secure binary. It's okay. Then I flash the secure binary. Then I will flash my SPSU. I launch again my turn-to-turn because I close it before and press the reset button of my target. So quite similar with what we have seen together before. So everything is ready, I would say. Let's see now how we will chip back the code. So in this package delivered, the only security that keep activated were the MPU privilege and the trace zone. This is the only prediction. All others have been deactivated. The boot lock because this is only in production. Once you have done this, you can change anything so you can break easily combined with RGP level one. But I don't want to go into details right now. Right prediction is not activated. I protect because we will activate it later. And ADP 0.5 or 1. And I deactivated them by default. And we will reactivate the ADP 0.5 after. So let's debug. So we need to create a new debug config. And we will remove the download of the TFMSBSFU because it's already flashed on our target. Then we will add the load of the TFMApplySecure and non-secure symbol. And then we will be able to debug. The difference step. First we will create a debug configuration based on the TFMSBSFU boots. Then we will remove the download of it. I go quickly because I will do it with you just after. Then we will add the loading of the symbol of the ApplySecure, the loading of the symbol of the ApplyNonsecure. And then we will put them in the correct order and this will be important before just debugging. And then we will be able to debug. Let's see this. So I come back to my cube ID. First I will create a debug configuration for the TFMSBSFU boot. So here I do a right click on it. Then I do debug as STM32 Cortex-AMCC++ application. So here we've got the main. We've got the startup. And you can see we are taking this one. We build it if needed. Or each time we will load this. We'll download and load the symbol. So I will just click on it and do the edit. I will remove the download because it's already flashed and I don't want to flash it again. Then I will add the secure application. So I just click on add, project, TFM Apply Secure. And for this one, I don't want any download. I just want to load the symbol. Sorry, I forget to select build configuration release and I don't perform the build also. So TFM Apply Secure release. Do not perform the build. Do not just download but load the symbol. Then I will add the non-secure application release. I don't perform the build. I don't perform the download but I load the symbol. And now what is important in the order because it will try to put a breakpoint in the entry point of different binary and I want to stop first on the TFM SBSF boot. So I will select it and I will move up. I want it to be on the top. I want the second one to be the Apply Non-Secure and the last one should be the Apply Secure. In this configuration, you can debug the three at the same time. So I will say OK, apply and OK. So by default, you will try to rebuild the TFM SBSF boot but here there is nothing to do so it's quick. Sorry my PC is a little bit slow. And then it will launch the debugging. I switch to debug perspective and I'm stopped in the main of BL2 main.c which is in fact the SBSF. So we are really at the entry point. So now I propose we will set some breakpoint before continuing. So we are stopped here. So we will jump again to the project explorer and I would like to put a breakpoint at the beginning or in the main of the TFM Apply Secure here just to see this jump and then just a breakpoint here just before jumping to the Non-Secure application. So in the TFM Apply Secure we have to select the core we can find the main line 189 and in the TFM SPM services you've got the Non-Secure entry. So let's put those breakpoint and in the Non-Secure application we go in the main.c just line 123. Let's experiment this. So here I go to the project explorer. Now I will go in the TFM Apply Secure I should go in the middleware because the entry point of the function is in the middleware trusted firmware code. Here you've got many files and the one that is interesting us is TFM underscore core.c So TFM underscore core.c I double click on the line 189 and it was the main I just put one breakpoint here. So here is the entry point I will say of the Apply Secure the main. Now let's check the TFM underscore SPM services. This one. If you double click on it go to the line 25 you've got Non-Secure entry. Where we jump from the Secure application to the Non-Secure application. That's it for the two breakpoints in the Non-Secure application. In the Non-Secure application we just go in the application user main.c and this time we put a breakpoint in the main which is line 123. So I think everything is in place now we can just start. So I will close this one this one and this one and I keep my execution in debug. I go back to the debug perspective. If I press continue here I am in the Secure application. So you can see TFM Apply Secure we are in the TFM core and this is exactly the jump before or just after jumping from the Secure boot to the first Secure application. Then this one will continue its execution and you can check the traces if you want in the TFM should be there. Yes we can see we are just there. So here I was about to jump in the Non-Secure application and I would like to show you something. Here you can see Secure this reflects the Secure state of your core that means your core could be in Secure or in Non-Secure mode. For the moment we are in the Secure application so we are in Secure mode. I would like to show you at assembly level how we switch from Secure to Non-Secure. So to switch to Assembly Code Stepping we click on Instruction Stepping Mode so click on this one the little eye then you should have the Disassembly window that is open and now we use Step-in. We use Step-in from several times and I would like to find with you the Instruction which is BLXNS branching to the Non-Secure Code. And in fact this is a new Assembly Instruction with CodexM33 which do the switch of context of the core between Secure to Non-Secure and on the next step if I step in I will switch to Non-Secure mode. So just to show you that we can debug at really low level and see whatever is happening in your system. So now we are on the reset handler of the Non-Secure application and if I just continue I will stop at my breakpoint that I put in my Non-Secure application and now I can debug it. So thanks this configuration so I'm still in Instruction level if you want to go back to C-Step you have to click and you can go home. So it's exactly what I want to show you because TFM is a huge code important not so easy to understand at the first look but here you've got all the tips to debug all this stuff together so you can have a look in the code understand how it works, experiment it. If I come back to my presentation I think we have covered all those steps and importantly yes let's terminate the debug session because if we don't do it right now we forget and we will face issue after for connection so don't forget to click on Exit Good So where do we stand? So first we experiment the TFM SBSFU functionality here we compile and debug the TFM SBSFU and the API secure and unsecure Next possible we will activate some hardware protection to the HGP the IDM memory protect and the HGP0.5 Again if you want to stop the hands on right now please jump to the board cleanup session it's quite important