 Hello, good afternoon and welcome everyone. We are happy to have you with us today for our webinar on STM32Q IDE for STM32L theories of microcontrollers. We will give a live demonstration on how to jumpstart a new project with the STM32Q IDE software tool and configure it as a trusted and untrusted application using the built-in features of the STM32Q MEX. Our security experts, Telen Maguller and Franz LeFlair will explain the theoretical application flow and project architecture and show you how to configure a microcontroller and put theory into practice. And now without further delay, I hand over to Telen. Hello and welcome to this webinar where we will introduce application development with STM32Q IDE for STM32L5 series of microcontrollers. My name is Telen and I am technical marketing engineer for general purpose STM32 or STM8 microcontrollers. Together with me is Franz, who will present application architecture and live demonstrate later. Let's start with today's agenda. Here you can see agenda used for today's webinar. We will split the webinar into three different topics. We will start with STM32 ecosystem overview, its collaterals and what STM32 offers to accelerate application development for STM32. We will then continue with brief overview about STM32Q IDE development studio for application development and debugging of the final application. Last but not least, we will show application overview followed by live demonstration by my colleague Franz. Let's start with our first chapter, STM32 ecosystem overview. What is STM32 ecosystem? It is a set of all collaterals required to develop application based on STM32 series of microcontrollers. We can split them into four different groups. Hardware development tools, those are the sets of different development boards and physical programmers to accelerate development to allow fast prototyping on STM32 microcontrollers. Second part is related to software development tools that is software running on your host PC and features configuration tools with our STM32Q Mx development or debugging tool with STM32Q IDE programming tool with STM32Q programmer and last but not least monitoring tools with STM32Q monitor. Let's move to the third point that is embedded software which is set of different libraries, 30 for drivers, high-level intervals such as operating system, Ethernet or USB stack and many others. And it also features expansion packages allowing customers to add its own code bricks and prepare specific driver package for their platform or final device. We have different offer for information and sharing starting with our ST.com website, product selector for PC or mobile phone to find appropriate device versus application requirements and we are present on all major social media where we put our latest news and upcoming events. Various types of hardware development tools allow you to get started seamlessly with any STM32 microcontroller. STM32 nuclear boards provide an affordable and flexible way for anyone to try out new ideas and build prototypes with a wide choice of specialized expansion boards. Arduino compatible and STMorpho connectors give ability to utilize onboard microcontroller with flexible prototyping capabilities. With a discovery kit, users can seamlessly exercise key features of any STM32 product lines while the evaluation board exposes all MCU functionalities. ST is working very closely with our partners who also provide different solutions of the hardware tools going from simple boards up to full evaluation features and fully open hardware. All these development boards include an integrated debugger or programmer as well as a comprehensive software library with examples that help developers to take advantage of STM32. STM32Q is our ecosystem offer for my controller development. It features software tools running on host computer and embedded software, a full set of libraries, drivers and middleware to support development application of the microcontroller. STM32Q tools offer complete development cycles. Starting with initial project configuration and cogeneration using STM32Q Mx followed by further development and debugging with STM32Q by DL. First step in the chain are programming tools to flash the microcontroller with compiled firmware. STM32Q programmer has been developed for that purpose while it also supports other command line or graphical features such as secure Bluetooth tech update for STM32WB and its essential tool for our secure firmware installation services. Once the final application has been flashed to the microcontroller we can start with last but not least important step that is long-term application monitoring. In our portfolio are now four monitoring tools last being added at the end of February 2020 featuring generic application monitoring based on node revs web technology. It features non-intrusive monitoring and gives full freedom to customers to build their own monitoring window. It is available at st.com slash STM32Q monitor. Embarrassed software features two different peripheral drivers either hardware abstraction layer or low-layer drivers that including different set of middleware and customer expansion pack allowing external partners or customers to prepare software that is compatible with our STM32Q offer which can later be used by STM32Q Mx to generate their code for the final application. STM32 microcontrollers and microprocessors are based on ARM Cortex-M or ARM Cortex-A processors therefore ST offers two different types of embedded software. STM32Q that runs on ARM Cortex-M cores offers generic drivers for microcontrollers either hardware abstraction layer to allow building applications rapidly and to be able to migrate to different STM32 seamlessly in the future or low-level drivers for those who want to get deep into the microcontroller peripherals and use its maximum capability at any given time. Included in the package is a big list of different middlewares starting with operating system, TCP-IP stack, USB middlewares and many more. To make the application development easier and more flexible we have firmware expansion packs allowing customers to import pack to the STM32Q Mx and generate the code from it with focus on their application, device driver or platform configuration. There are numerous of packs available already such as motor control suite pack, i-square prompt driver pack, sub-GFX expansion plug-in for graphics, NFC reader pack and many others. When we move to ARM Cortex-A world we are proposing open ST ring distribution for Linux applications. Our offer is based on Yocto and it's fully upstream supporting older hardware IPs inside the Linux. Our drivers and middlewares are from now on also hosted on GitHub where we are publishing updates and releases very regularly. Should you need safety ready drivers and software libraries we can assist you by providing relevant safety service or CloudBee library and all its associated documentation. Our customers value good database of information. We provide different channels where customers can find details about our microcontrollers. Starting with our website st.com slash stm32 is an entry point for our microcontrollers and microcontrollers and gives full overview and details about our offer. STMCU Finder is an application capable to run on PC or mobile that helps customers to find suitable MCU for your application and can immediately start STM32 QBMIX for initial configuration and code generation. MCU Finder will also provide a list of all documents linked with selected MCU. It is available for STM32 or STM8 service. ST has invested a lot of resources for our community and education platform. We have community forum available at community.st.com and special STM32 education page with our trainings and open online courses allowing customers to gain knowledge and get practical experience with STM32 by watching videos and following the instructions. Videos and trainings are also available at styoutube channel youtube.com slash stmicroelectronics. We are present on all social media where you can get in touch easily with us. Some of them are Facebook, YouTube, Twitter, LinkedIn and Instagram. That was general overview about STM32 ecosystem. Let's move now to STM32 QBID before we continue with live demonstration of the application development. STM32 QBID brings customers single tool solution for complete 3-in-1 software development. It integrates STM32 QBMIX like features including MCU finder for initial MCU selection, project configuration and code generation with our STM32 Qube firmware packages. Then it allows customers to write their own application code to compile it and download the binary to the microcontroller. Last step it features application debugging capability with step-by-step code execution including dual core microcontroller debug support or debugging of ARM Cortex M33 based devices such as our latest microcontroller STM32 L5 series. STM32 QBID runs on multiple operating systems including Windows, Mac OS and Linux. It is based on Eclipse platform and features GCC compiler with ST enhancements. Tool is completely free of charge for personal and commercial usage and is available at st.com. If we take a look at the screenshot of the tool on the left side is project 3 with files that are going to be compiled and linked together. Middle part is project open with built-in STM32 QBMIX allowing customers to change configuration and generate the code with single button click while watching actual C code changes in the third window where application is written afterwards. We have developed project importer from Atollic True Studio or software worldbench for STM32. This means that all previous projects developed in any of those two software tools can be now seamlessly migrated to STM32 QBID and development can be continued inside our tool. Furthermore, if you already have an iOS file for STM32 QBMIX project you can now import it into STM32 QBID and continue development in the single tool as shown on the right picture on the slide. Debugging is one of the most important steps during application development. Here I listed some of many features supported by STM32 QBID on top of its classical debugging interface such as code stepping, variable view, memory view and others. We are supporting currently STLINK hardware debugger available on every STM32 development board as well as Sega JLINK should you use it. Configuration is extensive and supports multiple choices in order to fit to your hardware setup. Life expressions have been added to support variable view while code is executed in real time without performance penalties. Should you need to display some data we do offer serial wire viewer where data can be graphically displayed in separate windows. There is an integrated UR terminal which allows you to use STLINK's virtual compute capability that is available in our nuclear or discovery boards. With our value line flashless products we propose code execution from external quad or octa SPI memory and therefore application needs to use external loader. We are providing external loaders for all our discovery or evaluation boards or we give you an ability to add your own loader to flash external memory directly integrate inside STM32Q by D. STM32Q by D supports multi-prodig debugging at the same time that is used with our dual core STM32H7 or trust-down enabled microcontrollers such as STM32L5. We will now demonstrate application development and debugging using STM32Q by D. One will present all steps to successfully prepare trust-down enabled application on STM32L5 with STM32Q by D development studio using its integrated features from STM32Q by MIX. So welcome to this live demo. First a short agenda. I would like to give you a short introduction about Cortex M30 Twitter Zone. Then I will describe the trust zone application we will create together and then we will create it and debugging it thanks STM32Q by D. First what is trust zone? In fact it's a new extra processor state with hardware regulation. You probably know the Harm v7 architecture with the Thrain mode and the Unreal mode. And switching to the Harm v8 you can see that we've got this additional state secure or non-secure. We still have Thrain mode and Unreal mode but we have a strong evaluation between the secure world and the non-secure world. If I take the example of STM32L4 we've got a Cortex M4. So we've got 1c stick, vector table, memory protection unit and stack pointers. We've got IP inside our device like user, timer, etc etc. We've got the flash where it's located our program on the RAM. Switching to the STM32L5 trust zone now look at the core. We've got 2c stick, 1 secure, 1 non-secure. The same for the vector table for the MPU and for the stack pointer. So that means it's as if we've got two states of the core. One secure, one non-secure. Regarding the resource it would be the same because the STM32L5 trust zone have an additional security and isolation at hardware level for peripherals and memories. That means the flash will be split in the secure part of the flash and non-secure part. The same for the RAM. Each IP could be assigned to the secure world or to the non-secure world. How are doing the switching, the switch between secure and non-secure? When you boot you're always in secure mode. So the secure code is executed. This one will configure the speed between the secure and the non-secure world and then the secure can always call or have access to the non-secure code. We've got a specific assembly instruction which is big NS. This one will imply the switch of context between secure to non-secure. But what is not possible is to directly call some secure code from the non-secure code. Here we will have an exception. So we've got an additional state but it's not a state I would say interfaces. That means the non-secure code could call the non-secure callable API and here we've got a specific instruction secure get which will switch from non-secure mode to secure mode and then this non-secure callable API will call the secure code. That means the isolation is done by defining very precisely the API of what the non-secure code can call as services in the secure code. And then we can come back from secure code to the non-secure code thanks to the big NS instruction. So it's quick. I go very fast on trust zone because it's not the purpose of this but what trust zone imply. In fact you will need two applications. One secure application which be located in the secure flash which will be executed at boot which configure the platform security. That means the split between the secure world and the non-secure world. Then it will call the non-secure application and it will implement some non-secure callable API. That way the non-secure part could call some services in the secure world. Not secure application it will be lodged by the secure application and should be located in the non-secure flash. And potentially it could call the non-service callable API. So as you can see many constraints not very easy to start. We will see that with stm32 cube id it will help you to start with a huge framework or old framework for this. So let's create an application together. First I will let's define it. What I propose is to use the stm32 alpha for sure and we've got secure world non-secure world to resources a lead and a button. What I want to do is to put the lead in the secure world and the button is a non-secure world and let's implement such kind of things. So first we boot in secure. We will configure the split between the secure world and the non-secure world. That means we will assign the secure lead or the GPIO that drives the lead in the secure world and we will assign the GPIO that under the public button in the non-secure world. Then we just jump to the non-secure. So we change the context and in the non-secure world we will just monitor the button. Is the button pressed? Yes. Then we will call a services which is toggle pin and this toggle lead will be take place in the secure context. Then we will come back to the non-secure. So quite simple application and you will see that we will do it quite fast. Which information we need? I would say which hardware resources we will need. It's a information of what is the GPIO for the lead and the public written. So we will use a nuclear stm32 l 552. If we are using the or looking at the user manual we can find that the lead is connected to the pb7 and the button is connected to pb7. So we've got all the information and now we will do the configuration of the board. So now I will need to configure my board or we say my chip because by default on the stm32 l5 the trezone is not enabled. So I will launch Q programmer. Let's connect to it. Go in the option by section and have a look in the user configuration. Here we've got the option by trezone enable. If it's unchecked you don't have trezone activated on your chip and we want to use it. So I just apply it down. Second thing I have to configure. The flash is divided in two banks and by default the booths are declared as secure. You can see the address here for the first region and for the second one here is the definition of the second bank. I want to remove the security of this second bank and use it where where I will store my non-secure application. So I will just modify it that way. I mean I put a higher address in the start regarding the end. This will remove security on this portion of memory. Perfect so my board now is ready to work in a trezone. I disconnect. Close it and now let's launch Q by G. So often if you just launch for the first time you should have this interface. So let's start a new stm32 project. You can also do it through this way. The target selector. So I can use both selectors or mpu selector. In our case I prefer to go in the mpu selector because I want to configure everything by my own. Here we've got the one associated to the nucleo. For your information in the docking resources you've got data sheet, reference panel, error sheet and many information about this chip. Let's define just the application. So it was the name of my project. I will use ccode. Trezone is enabled on my target for sure and we will use a project type of stm32cube because we want to define it thanks to our interfaces. Here we've got the firmware package used, the location of the repository and the way you want to generate code. I want to switch to the stm32cubemix perspective. Okay so those who are familiar with stm32cubemix know these interfaces. For the others it's quite simple. We've got the pinout and configuration. Here you can activate all the IP and define the pinouts. Then we've got the clock configuration. I will give you more about this after. So first you can see that for the connectivity just this example. For a result I can select to be insecure or non-secure. I can assign and will say this IP to the secure world or to the non-secure world. By default this is not the same because I can just remove the context and you don't see it there but just only in the mode and configuration but useful just to see it just here also. So I can assign it to secure and then vertically I can just configure my words that way. Okay just to show you how you can assign an IP to one world or to the another world. Quite simple. I just want to give a special word about this one gtsc which is a global trust zone controller. I don't want to go too much into detail but we'll say this IP is responsible for gathering all illegal access trust zones and generate IT associated to them. It will also handle the RAM assignation between secure world and non-secure world and also external memory. Okay so very important one you will see that in our secure code it will be automatically a code. By default the configuration is okay for us so let's keep it that way. Clock configuration. So here you've got the whole clock 3 and for the moment we are at 4 MHz but we can decide to go back to 110 and just request a system to compute what are the parameters to achieve this speed and you can see now we are on parallel it computed automatically. Quite useful. You can assign this configuration to the secure world also that means it will be done in the secure world and only the secure world could modify it. For the project manager IP and stack as you as usually I would say and that's it. So now let's configure our LED and our button. So for the LED you remember it was PB7 if I zoom in so it will be a GPIO output then if I do a right click I can enter a user label more convenient for programming and then here you've got the menu pin reservation. Here you can select to be secure or non-secure here quite easily. The LED will be powered to secure world. For the blue term this is 13. This time it will be a GPIO input sorry GPIO inputs then enter user label button and we will put it in the non-secure world and in fact we finish. We just assign the GPIO in the secure and non-secure world. The code is ready so just save it will generate the code for us. Let's have a look about the code generator. So we've got our Trezon project and inside in fact we've got now two applications. Okay so all the complexity to create the both applications and link them together is under by the STM32 QBIG. We've got the application secure and the application non-secure. You've got the associated linker file for each one. You've got the source code for both of them quite similar I would say but you can see that there is an additional one in the secure part whose name is secure underscore nsc.c Remember nsc non-secure callable. In fact it will have the link between the non-secure world and the secure world. The non-secure world will call some non-secure callable API of the secure world. So the definition of those API will be down in this header file and the implementation will be done in this file. Now I propose to have a look in the main dot c of each application so the first executable is the secure one. What do we have here? So in the main I share in it GTZC you remember the Global Trezon controller so here it's kind of a portion of the security is also configured here and we've got our GPIO in it. Let's have a look here for the LED we just configure the pin I will say as usual but you can see that for the button we configure it as non-secure. In fact by default all the GPIO are secure I would say part of the secure world so here we just need to declare the button GPIO as part of the non-secure. And we finish I will say for the configuration or the split of the secure world. This has been already down by the system. Next step will be to call the non-secure init function and this one is just a jump to the non-secure world and the context will be done the change of the context will be under automatically by the core. So if we jump to the main dot c of the non-secure world we've got just a share init system club config because we keep the configuration in non-secure world. The GPIO init here we just have the button configuration. Okay so we can see we've got both applications with everything is already ready for our implementation so let's start. First let's define the non-secure callable API. Okay something simple. And let's implement this API in the secure underscore nsc dot c. So let's do a copy pass to avoid error. What is important here is to add this attribute. These have been already defined in our environment. This one allow the compiler to add this secure gate instruction or the switching of the context. Okay so it will be the compiler which will take everything in charge. It will define the switching of the context push the register that need to be pushed into such kind of things. Just adding this one. Okay so now we've got the implementation of our API control space for completion. Here I just want to toggle the led GPIO port and the led pane. In fact that's it. I would say now we've got the definition of our API here. Here we've got implementation of our API with this specific attribute. You can see you already have some one API which is a secure register callback. This allow the non-secure word to register some function that could be called from the secure word. For example when the gtzc find an interrupt it can call a non-secure function if you register it and then just say okay there is a problem they'll give the violation. Please display message warning we have been attacked or something like that. This is just an example but for us we finish for our led toggling. Now let's go in the non-secure application. So what we need to do is just to monitor the level of the GPIO. So let's test it. So we just read the pin. So between GPIO port between pin and if this one is set that means someone push a button. So then how we call my non-secure callable API which is just this one. Okay maybe just add a show delay just to ensure we don't have too much toggling and that's it. So now we need to compile. In fact the booths are linked together because you will call here the API here so we need to compile a non-secure code also to compile the secure code. This is already under by the system in the properties you can see the project preference there is a dependency with the app secure. So when you compile a non-secure one you will compile also the secure one. If I just watch the application build here first you compile the secure one and then the non-secure one. Compilation is okay. Next step we want to flash and debug. So here let's create a debug configuration based on the non-secure. If we will have a look in the startup it will just download and debug the non-secure application but in fact I want to debug the booth. So let's add also the secure application just say I want the release one. I won't perform the build because it's already down by the non-secure application which builds the secure one but I want to download it and load the symbol associated. Perfect oh sorry I take the release one not good I want the debug one yes but I don't want to perform. Okay so everything seems ready. Last point we set a breakpoint in main but in fact we've got two main one in the non-secure one in the secure and with this configuration we will put a breakpoint in the main of the non-secure which is what I don't want to do. I would like to start on the main of the secure or stop on the main of the secure. So I will just move up this one and now I will show to stop in the main of the secure. Okay let's close the debug we are switching to the debugging perspective and now we are stopping the main which one in fact look at this we've got the GTZC in it so that means we are in the main.c secure. Okay here you've got the state of the processor we are in secure mode. Okay if I just run it break it I'm stopped software in the main HL Delay but if I click here we've got in the non-secure context. Okay so here it's a way to know what is the CPU state. Run it again and let's check if it's working first. If I push a button the LED is toggling. Okay so from a functional point of view we've got everything. So what I propose now is to see the switching context. Let's put a breakpoint just in toggle pin now I push a button and I stop in the toggle pin. What I would like to go now it's more in the assembly code so I will ask to instruction stepping mode and now let's have a look in the assembly code. If I step in step over step over I would like to show you when we've got this secure gate instruction. So look at the CPU state we are in a non-secure world here we've got this specific instruction and we are in the range of secure address. If I just do a step over we switch to secure world. Okay so this is really this instruction which do the switching between non-secure world to the secure world. If I step over I would like to see how we switch back to non-secure world. In fact it will be there. We just put a breakpoint go. We are still in the secure. It was a Bix NS branching non-secure. If I just do a step over we come back to the non-secure world. Okay so just to give you the detail about it. Okay so that's it we managed to build quickly this application. We are switching from secure world to the non-secure world and these are resources. Maybe I want to show you last things if I have a look in the register. You will see that there is some duplication of register definition. For example for our Bhutan PC13 we've got the GPIOC and we also have the Sec GPIOC. In fact it was the same IP but it was the way you assigned it to the secure world or to the non-secure world. Here the GPIOC or the C13 is assigned to the secure world and in fact in the non-secure world you can address secure world address but here we can only see I will say the input register of the Bhutan. If I just continue and push the Bhutan you can see the value that have been modified but we can see it in the non-secure address of the GPIO and we are in non-secure world. And symmetrically for the PB7 it should be in the sec GPIO but when we are in the context of the security. Okay so if I just stepping away in this way let's step in. So I come back to this one let's go to the secure gate okay here the register... sorry this one this one so PB13 secure is disabling if I just do so we are in non-secure world I go in the secure and now I can see the GPIO secure. Okay the configuration of the value. Okay this is really what I want to show you right now we managed to define our application quickly implemented quite easily I would say and we can debug it also. So thanks for your attention I hope you like this demo.