 Hello and welcome to part 4 of our STM32 Trust video series on TFM. In this video, we will compile, install and execute the TFM code on the STM32L5 SIS2 Discover Kit. Please refer to the previous video for a detailed instruction on how to setup the environment for the following steps. The steps we will go through are STM32L5 device installation, meaning preparation of the option bytes and configuration of the hardware. Software compilation of the TFM-SBSFU boot, TFM-Apply-Secure-No-Secure and TFM-Loader. Software programming into the STM32L5 microcontroller internal and external flash, and step-by-step execution and testing of the solution. As anticipated in the getting started video, a description of this procedure is included in the readme.txt file in the TFM folder. You can refer to this document for a description of the steps we are going to cover in this video. Another useful reference is chapter 10 of UM-2671. We will use this document for some reference and details of the next steps. The first step is STM32L5 device initialization. This consists in enabling the trust zone mode, disabling the security protections in the option bytes and erasing the flash memory. This step requires the STM32Q programmer tool. First, let's plug the STM32L5-6-2 discovery kit to your PC. Using a micro USB cable, we will use the STLIN connector to power the device and to have access to the STM32-2 SWD4 STM32Q programmer. To ease this device initialization procedure, an automatic script relying on STM32Q programmer CLI is included in the STM32Q file firmware package in the TFM sbsfuboot folder. In particular, you can find one for each of the supported toolchain. In this case, we are going to use the one for STM32Q by DE. Opening the file, we can see that STM32Q programmer CLI is being used. At the top of the file, we have the definition of the option byte parameters that will be used in each step of the script. A regression to RDP level 0 is performed together with the enablement of trust zone. Bank 1 and Bank 2 existing protections are removed if active and the flash is erased. The HTTP protection is removed. Then the default option byte configuration, neither for the TFM application, is applied to both Bank 1 and Bank 2. Going back to the folder and launching the script, we will see STM32Q programmer command line interface going through the steps and performing the option bytes configuration that we just described. Another option to perform the regression is to use the STM32Q programmer graphical user interface following the structures reported in user manual 2671 section 10. This procedure will guide you in the configuration of the option bytes using the STM32Q programmer graphical user interface. The output of both procedure will be the same. Now that the STM32L5 configuration is ready, we can focus on the next step that is the compilation of the application. The following section is based on the description included in the user manual 2671, in particular in section 10.2. The compilation process is performed in four steps, as indicated in the figure. Because of the dependencies between these projects, it is important to build the TFM related projects strictly following the order described here. Step 1 is the build of the TFM SPCFU boot application. The project is included in the TFM SPCFU boot folder, and in particular we will be using STM32Q by DE. Opening the project, it is imported in STM32Q by DE workspace. At this stage, a few configuration options are available before building. That could be useful during a development phase. The file boothalconfig.h, included in the boothal.c, is the entry point for configuring the security features of STM32. Opening the file, you will find a list of bound define that can be used to enable and disable write protection, HTTP, and all the other security features. For the following sections, we will consider the default configuration with the security APIs enabled, but disabling these APIs could simplify a first evaluation of the system. Now we can proceed with building the project. Clicking on build, the user app, the middleware, and all the files are compiled successfully. The project is also configured to launch a postbuilt script that prepares scripts that are needed for the following step. That is, the building of the TFM Uplit secure project. This step creates the TFM secure binary, and through the postbuilt command integrated in the IDE project, it produces the TFM secure signed image in both clear and encrypted form. These images will be useful during the developments for testing the firmware update procedure of the secure image. The TFM Uplit project is included in the related folder. Please note that this project includes both the secure and the non-secure application images. We will start with the compilation of the secure, and then move to the compilation of the non-secure code. Opening the project in the stm32kbd folder, it will be correctly imported in the IDE. And here we will find the two non-secure and secure projects included in the workspace. Now, selecting the TFM Uplit secure projects and clicking on build, the build compilation steps will start. The middleware, the source code, and all the high libraries will be compiled. The binary is created, and then the postbuilt script is also executed. Now that we completed the building of the TFM Uplit secure application, we can move to the next one. This is the building of the non-secure application. The non-secure project is already loaded in stm32kbd as we saw in the step before, so we can select it and launch the building. The compilation is completed successfully. The binary is created, and the postbuilt script preparing the signed non-secure image in both encrypted and clear form is executed. The final step is to compile the loader project. The postbuilt script automatically called by the IDE creates the TFM loader image that will be flashed in the device in the next steps. The TFM loader is included in the related folder, so we can enter the stm32kbd folder and load the project with the toolchain. Similarly to what we saw for the other projects, the project is loaded correctly as the TFM loader, and we can proceed with the compilation. The source code is compiled, the binary is created, and also the postbuilt script is executed. This concludes the compilation step. Now we can proceed with the installation of the code in stm32kbd using stm32kbd programmer. Also in this case, to ease the installation procedure, an automatic script based on stm32kbd programmer command line interface is included in the package, in particular in the TFM sbsfu boot folder. A unique version of for each toolchain is included, so in this case we will open the stm32kbd folder and use the TFM update script. Opening the script we can see that stm32kbd programmer CLI is being used, the configuration file for the external memory available on the stm32l562 discovery kit is loaded, and the addresses where each binary prepared in the previous section will be flashed and specified. Please note that these locations depend on the project memory configuration. You can refer to the documentation for further details on how to configure the memory mapping of the system. The script will first flash the secure and non-secure image, then the TFM loader, and finally the sbsfu code. Before starting the script, it is important to remember that your discovery kit has to be powered on and connected to your PC. Another step to do before launching the script is to open a serial emulator that we will use to connect to the board and to make sure that the TFM application starts correctly. For this section we will use the return. We can setup the serial communication, selecting the comport associated with the discovery kit. In my case it is com16, you can check the comport assigned on your side in the device manager looking for the stlink virtual comport entry. Then we need to specify the connection parameters as indicated, and we can click on OK. The comport is now open and ready to print the output of the TFM application running on STM32. Going back to the folder and launching the script, we will see it going through all the steps that we just described so the TFM app plays secure and secure, the TFM loader and the TFM sbsfu will all be flashed into the STM32. Now we can press the reset button on the discovery kit and follow the very first execution of the TFM sbsfu project on STM32. The code checks the option by status and applies the relevant changes to setup the protections according to the configuration specified at compile and linker time. At this stage, because we configured RDP level 1, an intrusion is detected by the microcontroller and execution is frozen. In order to recover from intrusion mode, we need to remove jumper 2 from the STM32 discovery kit and then put it back in place. Let's remove the jumper and then put it back. The system restarts and the secure boot code is executed. After the initialization of the secure boot order features, for example the non-volatile counters used for tracking the image or visions, the signature of the code is checked, the undefined encryption for execution for external memory is configured, the secure image is initialized, and finally the user application is executed. Now that the application is installed correctly, we can test the security guaranteed by the TFM design and explore the TFM secure services provided to the non-secure world. Going back to the terminal, we are prompted with the user app menu options. Let's start with pressing 1. We will see another menu and we will press 1 again to test the behavior of the system when non-secure code tries to access the secure world. The system will go through a few tests. Scrolling back, we can see that different attempts to access specific sections in the secure sram or the secure flash are blocked. All the intrusions cause a secure fault. Access to the secure world is prevented and the reboot is triggered. And finally an overall result of the test is provided. This leads us to the menu we saw before, from where we can now proceed with the testing of the TFM secure services. Pressing 2 here, we enter the TFM examples menu. In here you will see a list of tests demonstrating secure cryptography and digest services, secure storage, SST and ITS, and attestation services. We would recommend you to refer to the documentation and the code implementation for further details for each test. Pressing 0, we go through all the tests one by one. And also in this case, an overall summary of the result is presented. Now that we tested the execution of the non-secure app, we can explore how to perform a secure firmware update. The user application version we are executing is version A. We now want to update it to version B. Going back to the non-secure application source code in STM32Q by D, we can update the version editing the file main.c. We can look for the user app ID variable and change it to B, and then compile the code as we did before. The possible script automatically triggered by the compilation will create the firmware image that we can use for the secure firmware update. The secure firmware update procedure is handled by the TFM loader that we saw before. In order to start its execution, we need to reboot the system, keeping the user blue button pressed. Going back to the terminal, we will be prompted with the local loader menu, where we could choose to update either the secure or the non-secure image. In this case, we want to update the non-secure image, so we will press 3. The download area for the non-secure image update is erased. And then we can use the Ymodem communication protocol to send the new firmware image. Click on transfer Ymodem send, browsing to the TFM application folder. In the binary folder, we can find the TFM non-secure signed firmware image. A couple of things to note here are that as a result of the possible scripts in both the secure and non-secure application compilation steps, this folder includes also the binaries of the secure firmware image. And in addition, both the secure and non-secure signed images are also available in an encrypted form. In this example, we'll use the non-secure firmware image in clear, but the same process will work for the others. Please refer to the documentation for further details on the available options. Now selecting the non-secure signed binary and clicking on open, the Ymodem download will start. When the download is completed, we will manually trigger the reboot of the system to allow the secure boot code to verify the authenticity and integrity of the new image and to proceed with the installation. Pressing 1, the secure boot code starts. The signature of the image is checked. Then the new firmware image is installed, replacing the old one. The secure boot code then proceeds with the regular state machine checking the integrity of the whole system. And finally, the new firmware image version B is executed. This concludes this Part 4. Thank you for your attention and please refer to st.com.stm32trust for further information.