 Hi, again. I'm Bob Waskiewicz with ST Michael Electronics, staff engineer, back at you with part two of our nine-part video series on the STM32L5 with trust zone. In part one, we introduced the STM32L5 along with the ARM Cortex M33 core. In part two, we introduce you to the STM32L5 nuclear board, which is a hardware development board. We also introduce you to the STM32Cube programmer, and we introduce you to some features of the STM32 nuclear board. Again, if you look at the notes of this video, you will see a link pointing you to the hex files, which are used in the hands-ons of the nine-part video series. The purpose of hands-on number one is threefold. First, introduce you to the L5 nuclear board. Second, introduce you to the STM32Cube programming tool, which is a pretty cool development tool as well. It's not an IDE. When we discussed having this virtual hands-on, the idea of installing an IDE and compiling and licensing and all that stuff just got to be too complicated. So we're just going to basically take hex files and download them using the Cube programmer. And the third reason for hands-on one is to validate the driver side from the PC down to the nuclear board. All these devices have embedded SP link version two or version three in them. And there's some USB drivers that need to be validated as well. So blinking number one is a legacy mode, which I'll call of the L5. Trust zone is disabled. We're just going to download some code, blink some lights. The current version of the nuclear you have should also have a running code that's blinking the red, green, blue LEDs. We're going to make them go a little faster. And that's how you know you succeeded. Here's a little marketing information about the STM32Cube ecosystem. ST over the past several years has allocated a lot of resources. And I think we've come up with a very good ecosystem. I use it all the time. In addition to the Cube programmer, which we're going to be using for this hands-ons today, there's also a Cube MX, which is a configuration type tool. Allows you to take any of the STM32 devices and configure them. It'll generate startup code for you in one of three IDEs, IAR, Kyle, and then, of course, our new Cube IDE, which ST purchased Apollic a couple years back. So the Cube IDE is the GNU based on True Studio. We also have the STM32Cube monitor, allows you to monitor several different communication paths, can allow you to do low power monitoring. So that's a pretty cool tool. In addition, we have library packages, which we'll call the Cube MCU packages, and I'll introduce the L5 in a minute. And then we have these Cube expansion packages, which typically are grouped around unique functions. For example, we have a crypto library expansion package, we have a MEMS expansion package, all kinds of expansion packages. So go to www.st.com.slash.stm32cube and you'll get started. The cornerstone of our STM32Cube ecosystem are our STM32Cube MCU packages. These are full source packages, libraries. They include both a HAL, hardware abstraction layer, which the intent was created to easily allow a user to move amongst STM32 families, meaning if you've figured out how to use the UART on an L4, when you move to the L5, the HAL takes care of the low-layer interface and you basically just start writing your application using the HAL. However, people did say that the HAL was bloated. So then we came up with our low-level drivers, APIs, which basically our rights to registers is what it is. There are full example projects, which support the three IDE's I mentioned previously, IAR, Kyle, and our Cube IDE. And in addition, we have those Cube expansion packages, middleware comes from FreeRTOS, some for FAL system, there's many, many, many of them. So again, stwww.st.com.stm32cube L5, the examples that we're using today came directly from the L5 Cube package. The hardware support for the ecosystem comes from three types of boards. The nuclear board, which we're using for this hands-on, we also have discovery kits, which are uniquely accenting certain features of a particular device. And then we have the full-blown eval boards, which have everything, all the bells and whistles that you could imagine. We will be using the L5 nuclear board. It consists of an STM32 L552 with the dash Q option, which includes 512K of flash, 256K of SRAM, and additional internal support for switch mode power supply, which is on this board. So the power performance is really good. There's a built-in STLink V2, which allows us to connect to our PC, uses the debugger for the IDE, uses the download interface for the Cube programmer. There's a couple LEDs, actually three LEDs, red, green, blue, we'll be flashing those. There's some switches, push button, user and reset, we won't be using the user, we'll be using the reset. IO expansion, so all the pins of the LQ-144 are brought out. There's also an external link to this SWD debugger, which is the JTAG interface. So the top board breaks off if you wanted to use this as a third-party debugger of your target system after you built it. There's also some power supply options, which we will be using. On hands-on one, two and three, we'll be allowing the STLink, the power of the board. When we get to hands-on number four, we'll be doing the power to the board through the USB Type-C connector. We will be using the STM32Q programmer to download hex files onto the L5 device. We will use it to erase flash, we'll use it to set option bytes, which will enable the trust zone and we'll also set up some watermarks for the flashing, which I'll get into in later slides. The Q programmer has a lot of features, not just the STLink interface, but there's also a UART, SPI, I2C, CAN interface. So a very powerful tool. And there's also this secure firmware injection programming. It's a pre-provisioning tool. There's also a trusted package creator that goes along with this. Don't have time to get into that today on this short two hours, but something you might wanna investigate on your own. Some housekeeping for hands-on number one. So ST has built all the L5s with the trust zone in them. The trust zone is activated by setting a bit. So from the factory, it's turned off. Then with the trust zone turned off, it's just like a normal MCU with great power performance characteristics and some great features that can be used as a normal micro. The starting point for hands-on number one was the QBEL5 version 1.2 library. I took the GTIO toggle for the L5 nuclear board. All the examples are based on board support packages. So I showed you the eval, the discovery board. This was a nuclear board. The trust zone is disabled in this. So it will not run if you enable the trust zone because there's things you have to do. It was compiled under IAR version 8.4, and as a IAR project, you have to identify whether the trust zone is enabled or not, and I'll talk about that in hands-on three when we talk about the tool flow, but you basically have to tell what's secure and what's non-secure when it comes time to create a project. As I mentioned, the starting point was the original source files in the library. I did make a couple of modifications for the LEDs. In this case, if it's got a blue box around it, it was no modification. This is a call to the GPIO init, which I'm gonna show you. I just added some pins to that, but also in the main loop, while through, we're gonna toggle all three LEDs instead of two. In the physical GPIO init call, I added the configurations of the clock for the IO ports and the physical pins that the LEDs are fixed to. Under the IDE, there is some type of configuration. I'm using IAR. The trust zone is disabled in this device, so the compiler does need to know whether you're compiling a trusted or a non-trusted when the trust zone is enabled. When the trust zone is not enabled, it's a normal project. Kyle does its own thing. The cube IDE does its own thing as well. Okay, here we go. First, let's make sure that the power source is correct. So we want to set the JP6 jumper to power from the ST-Link V2 onboard, which is a default from the factory. Next, you wanna take the USB type B cable. I'm gonna plug it into the nuclear board. Then we wanna find just the vacant port on our PC and plug it into that. This will allow the PC to supply power and then the cube programmer to talk to it. If all is good, when you plug the cable into the host port on the PC, the system will recognize itself, the USB driver will be installed, and things will go good. Handle number one assumes that the factory default condition of the L5, so we're not gonna change anything. We're just basically gonna talk to the board now through the cube programmer. Now that we have the nuclear board connected to the PC, go ahead and locate the cube programmer icon on your PC, whether it's on the desktop start menu, test bar, and start it. As the cube programmer comes up, it's gonna initiate itself, but then it's also gonna look at the ST-Link, and they're gonna see the physical board connected, even though we haven't connected the tool to it yet. So you'll get this warning message, error message that the ST-Link is not connecting, and we'll take care of that on the next step. So the default communication port for the cube programmer as the ST-Link, nothing to do there. There's a selection for the type of connection, and we need to make that a hot plug. So you're gonna have to do the pull down and change that to hot plug from normal. Once you do that change, go ahead and hit connect. Once you connect, you'll see some information come up in the login window similar to this, and you'll also see additional information in the lower right-hand corner, and this indicates that DL5 is now connected to the tool. Next, we're gonna select the open file tab at the top, and we're gonna go ahead and browse to our first hex file, which is gonna be the hands underscore on underscore one dot hex file. And once you download that file, you're going to see a new window open up, the tab with the actual hex information, some connection information. Also take note of where the file is going to be located. The default for a non-trust zone and for a normal SDM32 is 800,000, and that's where this application starts. Go ahead and select the download icon, adjust your window to see all the options that you have available. We're gonna browse again to the hands on underscore one dot hex file. This is to show you that the editor tab where we loaded the hex file and the downloading tab care can be two different files, and this is how you would set it up. So now we want to actually erase the existing program in the L5, which by the way, you should be seeing some LEDs flashing, red, green, blue at a slower rate. We're gonna make them flash faster. So I want you to uncheck the skip flash erase before programming because we do want to erase each time. I want you to check verify programming. This will make sure that after the device is programmed, it'll verify it against the file that we opened. So go ahead and select the start programming. So actually these messages are backwards because of the fact that you're gonna get the download verified successful first, okay that, and then you're gonna get the file download complete, okay that. So note the log window information because it's a sequential effect. That's why they're backwards. So you go back to the file edit icon. It's gonna open up the tabs where we actually loaded the hex file to start with. I want you to disconnect from the STM32 L5 nuclear board. This will give us the same starting point for the next hands-on. Note the login window will give you a disconnect message. And then I'd like you to close the actual hex file so that again, we're starting from a known point when we begin hands-on number two and number three. So in order to execute the code that we just downloaded, just press the reset button and then LED one, two and three, red, blue, green will sequence across at a little faster rate than you saw previously with the default configuration. This concludes the hands-on number one. Once again, thank you for participating in the nine part video series on the STM32 L5 trust sum. I encourage you to continue with part three in which we will go a little deeper into the ARM Cortex M33 trust zone architecture itself.