 Thanks Chris. I'll now go into more detail about our bare metal support package. I'll cover why customers are asking for it, what we deliver and how to use it. So, why bare metal support? More and more often, end customers are finding that they're reaching the performance limits of their current microcontroller families. They need more performance but don't necessarily want to step into the world of embedded Linux. Or it could be that embedded Linux is just not suitable for their end application. Or perhaps they want to run a real-time operating system like Azure Autos. There is another reason why bare metal is useful. During the board bring-up stages, quite often the person that performs the initial software bring-up and testing of peripherals is the person that developed the hardware. Sometimes, not always, but sometimes that person is not familiar with embedded Linux. They may not have an embedded Linux desktop machine to work with and they're not familiar with device tree and Linux board support packages. So bare metal is really useful to be able to write simple C test routines to exercise peripherals on the chip without having to step into the whole world of embedded Linux. So this is useful even if your end application is going to be Linux but the initial board bring-up is done just with bare metal routines because no Linux knowledge is required. So what do we deliver with our SDM32Q MP13 bare metal package? So it's a set of examples and obviously all of the device drivers to run bare metal on the MPU. So in terms of how peripheral examples, we have standalone QBID example projects for all of our individual peripherals that exist on the microprocessor. These are standalone examples that you can import into QBID and use as a basis for your own examples. We also have some template projects for you to start from scratch essentially. We also support Azure Autos on the MPU. Azure Autos by the way is becoming Eclipse ThreadX now that Microsoft has passed over governance of that project to the Eclipse Foundation. So right now in our package you'll see references to Azure Autos but moving forwards we'll obviously move towards Eclipse ThreadX. So in terms of Autos examples, we have examples using the kernel itself ThreadX. We have examples using the file system FileX, NetworkingStack which is NetX Duo, USBStack which is USBX. On top of the how peripheral examples in the Azure Autos examples, we have a first stage bootloader that will allow you to load code into external DDRST RAM memory. We also have some flash programming tools that currently allow you to program an SD card or serial nor flash on the device so that you can program your application into the flash while it's on the board. Our development tools, Kube IDE and Kube MX also now have new project wizard support so that we can create a bare metal project from scratch within Kube IDE and we'll show you that during the demo stages. So where would I get this SDM32 cube MP13 HAL library? So if you're familiar with our Kube tools or Kube IDE or Kube MX then you can download the packages you just would do any of our normal MCU packages using the embedded software package manager and it will look like this here. You can also download the source code directly as a zip archive from sd.com and this is a link if you click in the presentation when you download the presentation that will take you to sd.com and where that download is. Also, ST now support posting of our firmware packages on GitHub so you can go and git clone the sources directly from GitHub. So taking a little look at the overall architecture of the package. Obviously at the bottom level of the software stack we have the hardware itself and we have some development kits for the MP1 processor, for the MP135 it's the MP135 discovery kit. And then in terms of software on top of that we have all of the what we call the HAL, the hardware extraction layer. These are the device drivers for the individual peripherals on the chip. These are available either as fairly high level extracted libraries, which we call the HAL, but if you're sensitive about code space sizes then we also have some lighter weight device drivers called our low layer libraries. On top of that we also have some support packages for individual peripherals that are on some of our demo boards. So for example, support for ethernet 5, support for displays etc etc. So this is the device driver level and then on top of that we have the RTOS and middleware level. So in this particular case we have a Zure RTOS, the actual operating system itself, and all of the middleware that comes associated with that as we discussed it's USBX, NetX, Duo etc. But we also include ST's own USB device library for device and for host. So if you don't want to use a Zure RTOS for example but you still need USB support then we still supply the USB device and host stack libraries to run on the NPU. And then at the top level we have a set of examples and application level examples and applications are more fully featured examples. The package also contains some utilities for creating binaries with the correct header format which we'll discuss later in the presentation. So in terms of the package directory structure it will look very very familiar to you if you've used any of our microcontroller family HAL libraries before. So for example we have the device driver directory and this includes all of the standard HAL peripheral device drivers both low level and at the HAL level for the NPU. We have a middleware directory and this contains all of the source code for the Zure RTOS that includes the operating system itself, ThreadX, plus all of the middleware, plus our USB host and device libraries. And we also include a Simsys RTOS adaption layer as well for ThreadX. Then we have the projects directory and in the projects directory we have all of our application examples and templates. So there are two sub-directories, one for the DK board which is the publicly available MP135 development board and then another one for custom board examples. Because although the DK board has a large number of peripherals on it it doesn't include every single peripheral that we have on the NPU so no S nor flash for example. So we have some custom examples that allow you to see how you would use those peripherals even though they're not supported on the DK board. And then finally we have a utilities directory and in there we've got something called the image header utility and this is used to generate wrapped binaries so that the ROM code will recognize your own application and boot it at startup. So how do we use these examples? So all of the how-proof examples are small enough to run from the microprocessor's internal SRAM. There's one exception to this which is the LCD controller example but all of the rest are small enough to run from the internal SRAM. And the internal SRAM on this device is 128k bytes. Now obviously for a real world application you will probably still need to load the example into external DDRSD RAM. We have some utilities to help you do that. But when running the simple examples in SRAM they're loaded into the SRAM of the device directly using the QBIDE debugger. So in QBIDE we can connect to the target and download the code into SRAM. And to make that life easier we put the NPU in what's called developer mode and I'll explain what developer mode is on the next slide. So it's still possible to boot the application from external memory like SD card for example without having to connect your debugging cable and your QBIDE. But by default the application will still run in internal SRAM. Also for the ROM code to recognize your application it needs to be wrapped with a special header so that the RAM code will recognize it. If you wish to run your application from external SD RAM memory which most real world applications will need to do then first of all you need to initialize the SD RAM controller. And we have a couple of examples to do that as part of the package. The first one is the DDR init application and this basically just allows you to initialize the memory controller and then you can use the DDR SD RAM at that point to run your own application from it. So we also have a first stage bootloader application and we've got two versions of it one for bootloading from SD card and there's another version for NOR flash as well. And this application boots a simple bootloader from in this case the SD card and configures the SD RAM for you and then loads your main application into SD RAM. The Azure Artists examples are obviously more real world size and therefore they're too big to run in internal SRAM. And so they must be configured to run from the DDR SD RAM which means that the SD RAM first of all needs to be configured first. And you can do that as we just discussed with the DDR init program or the first stage bootloader programs. So the simple peripheral examples, when we load them with cube IDE we put the device into what's called developer boot. And in some documentation you may see it referred to as engineering boot. And this is just a special boot mode where we set the boot pins so that the Cortex A7 device literally just sits in an infinite loop. It's toggling one of the port pins PA13 and it sits in an infinite loop. This is useful because as part of that we re-enable the debug connection. So by default when you load a program via the ROM code and it starts its bootloader one of the very first things it does is disables the debug connection. Which means it's a lot harder to actually connect a debug cable to the device. So to make life easier we ask that you set the board or set the MPU to boot into developer mode, developer boot. And then it just sits there waiting for you to connect a debug cable. Now just to make absolutely clear, when you secure this device so that it will only boot from an authenticated and secure boot flow, this developer boot mode is disabling hardware, it's no longer accessible. It's just there for the development process of allowing you to easily connect to the debugger. So I mentioned before that if you wish to use code in the SD RAM then first of all you must configure the DDR SD RAM controller. And we provide an example of how to do that. This is called the DDR init example and it's in the example sub directory for the example projects. What it does is you load it into memory using cube IDE. It will initialize the clock tree of the processor. It will initialize the power management IC if you're using one to make sure that all of the power rails are correctly provided to the SD RAM. And then it will actually initialize the SD RAM controller in itself so that now you can actually access external SD RAM memory. Now at this point it will sit in a constant while loop so allow you to simply connect your debugger via hotplug. It's not a bootloader but it's intended to allow users to configure and use SD RAM prior to running their own application. If you want to implement a bootloader we have a separate example for that which I'll talk about later. So the ROM boot process it's important to understand this before we can move on to understand how we boot things from external memory like SD card for example. So when the ROM code starts it searches for the very first program or the first stage bootloader from the selected boot device. So it reads the boot pins, determines where to fetch the first stage bootloader from and then goes and looks for it. Now it recognizes the binary to execute by looking for a specific header. So it looks in the storage location for your executable and it looks first for a header with a magic number. This header also contains the entry point address for the specific application. So the ROM code looks for a header file, it loads the header into internal memory into SRAM block 3 which is a small block of memory. And then it loads the remainder of the program into what's called sysRAM which is 128k block of internal SRAM memory. It checks the header file for the entry point address and then sets the processor executing of that entry point which in most cases is the first stage bootloader address. If you want to know more about the header file format this link here takes you to the MPWiki article about the header format. So in our Linux flow the header is automatically generated for the bootloader as part of the TFA build process. But we're not using Linux here, we're just using a bare metal development flow. And so we provide a utility to generate this header for you. So in the utilities directory as part of the package you'll see the utilities directory and then within there we've got a subdirectory called image header. And in there there's a script file that we use and it gets called to generate the correct header information for the binary that you've just produced. Now this script will call an executable and we have a Windows executable that can be used for Windows hosts. But we also have Python executables that will run on in a Linux environment. And if you want to know more about how to use this then there's a readme.txt file that accompanies this utility. So this image header utility is included as part of the build process. So when you build your application the very last steps are to run this script which will take your binary file and add the relevant header information to it. And the way we do this is that we add a post build script within the kubidee tool. So we go into the tool, we configure in the project settings that we add a post build step. And we refer to this script which means the script gets called after each build. So once we've got our binary and it's been wrapped with the correct header we then need to program it to our external memory. So in this case we're talking about SD card and we need to understand a little bit about how the ROM code views the SD card in terms of boot process. So when the ROM code is booting from the SD card it will search for the first stage boot loader or the first executable file and it will look for potentially look for two copies of this because if the first copy is damaged it will then load the second copy. But it finds this first stage boot loader in one of two ways. So initially the ROM code will look for what's called a globally unique ID partition table or a GPT partition table. This is simply a partitioning scheme used for modern disks. And if the ROM code finds a GPT table then it will simply locate the first stage boot loaders by looking for a partition entry beginning with the name FSBL. If no GPT table exists then the ROM code will fall back to using the LBA addressing mechanism and it will look for the first stage boot loader at LBA address 128 which is hex offset 10,000. If it can't find a first stage boot loader there then it will check address 640. And more detail of this boot scheme is available in this link here. So we have included as part of the package a very simple first stage boot loader application. We have two versions in fact. We have one that will load from SD card and one that will load from SNOR and I'm talking about the SD card example here. And it's an application, a simple application that you load onto the SD card and the boot loader will fetch this application from the SD card and start it executing. So the first stages are that the ROM code starts executing. It goes to the SD card and it fetches your first stage boot loader SDMMC application. It loads it into system ROM, into SROM. It executes this application and this application will then configure the clocks of the NPU. It configures the DDR controller and initializes the SD controller so that your bare metal application now can access the SD card. It will then copy all of the information. Well first of all it checks in the header file how long the binary is and then it will copy the length of that binary into your external SD code. Finally once it's done that it will jump to the execution address specified in the header and it will start executing your code from DDR SD RAM. And the way it's organized in terms of the SD card layout is as we said in the previous lines the ROM code will look for the first stage boot loader at physical address LBA 128. So this is where we load your FSBL SDMMC application and its header file. That is loaded into internal SROM. It executes, it configures the DDR controller and then it goes to a specific address LBA 640 and that address there is determined by the first stage boot loader application. So you can actually move your own example up and down the memory region if you wished but that copies it into SD RAM and executes from SD RAM. So we also have some utilities for programming external flash. So it's fairly easy to program a micro SD card in the Linux world with custom partition schemes but it's a lot more difficult when you're using Windows. So we have an executable, well a binary application that will run on the MPU and it works with Qt programmer to allow you to program your SD card with your relevant binaries. But we also have a version for SNORE flash so if you have SNORE flash soldered to the board and that's your boot source then you don't have to obviously program the chip before you solder it to the board. We have this utility and the utility essentially is a binary that runs on the MPU, interfaces to Qt programmer and then allows you to run this simple loader on the MPU to program your main application into the external flash. So both tools will communicate with Qt programmer either via the UART and the SNORE programming utility also has a USB DFU capability as well. This is currently not implemented for the SD card tool but it's coming basically and also as it stands right now this loader program is provided as a binary only. Now source code is available on request but we're also planning to release it, the source code is a later release to mass marking. Ok that's in the planning. So finally we have some useful links I hope on many of them relate to our STMPU wiki. And these links talk about the actual MP13 bare metal package itself and has some tutorials about how to actually start running with it and to load external applications. So that's it for the theory section. We'll now go to a short hands on so I hand back to Adela. Thank you very much.