 Welcome to the set of hands-on for bootloader, and this is going to be the first one, which will be focusing on a very simple bootloader only. The main purpose of this hands-on is to have a standalone bootloader separated from the main application. For that purpose, we will need to define memory map to reserve some space for bootloader, and we need to make sure that the bootloader is able to jump to the application. For the application, that will be the same as the one that we used in the former protection hands-on. Still a very simple application. The only difference is that this application will run from a different address on the flash. After we build both projects and download the binary to the board, we will be able to observe the jumping from bootloader to the application. Similar to the former protection hands-on, we will still be using the Nucleog0.7.1 RB board, and the same set of tools and software to be required. Make sure you download the hands-on package, and you have the Q-Programmer, any one of the three IDs listed here, and also a Terminal tool on the PC to get a print message from the board. We're going to use two projects from the hands-on package, one for the application, and the other one for the bootloader. This is a flash layout that we're going to have for the bootloader and application. So we reserve 32K bytes for the bootloader. Of course, as a very simple bootloader, we will not consume such a big area, but later on when we have a more enhanced bootloader, the code size will be bigger. So currently we reserve this size for the bootloader, and application will start from this address, 08008200. Here, between these two, we reserve five child bytes for the metadata, for the application. Again, this space will not be used in this first hands-on for the bootloader, but will be used later on. Okay, we are ready to go. Let's start. Now we start the hands-on for bootloader. This is a first hands-on for bootloader. So we're going to have a very simple bootloader just doing the jumping from bootloader to the application. So for the application, that will be the same as the one that we initially used in the former protection hands-on. That is exactly the same, just with some print message and also LED toggling, that's it. But right now we will have a standalone bootloader and also a separate application. So in this case, we're going to have two projects, actually. So here we, still, we will use the pre-generated project. In this one, GZero app for BL is application for bootloader and we will have also a very simple bootloader project in the folder GZero BL. And as I said, this project is actually the same as the previous one, simple application, almost the same. There is just one thing that is different, which is the starting address of the former is moved to a different location. It's not anymore the base address of user flash because we are going to start from bootloader instead of the application. Okay, so we can again open this project. This will be this one. You can close those files. And we take a look at, so again, this is the same thing. We just have a print message and then call the application and the application is also the same. Running a test function and then toggled LED, that's it. So what is different this time? The different thing is the starting address. Okay, so we should take a look at what is changed in the linker file. So previously the application was start from A00000. But now we have moved the start address to a new one. So there will be offset. That means the application starts from 8200. This is a new address. Why 8200? Because we reserve 512 bytes for former metadata. It's not used in this and some, but will be used later on. When we have the former verification from bootloader, we will use that area. Okay, so that is something changed in the linker file. Of course, if you look at the linker file from IAR or KL, you will find similar things. So the start address will be modified. Apart from that, there is also another thing need to be modified, not this one. We can take a look at, we can take a look at, for example, the IR project. So usually you will have a system.cfile where you have the vector table offset defined in the code. Vector table offset defined in the code. Previously, we should have offset set to zero, but this time we set this offset to 820, to be in line with the linker file. Okay, you have the same thing, similar thing, the other IDs. So then you can just compile the project. Of course, at this moment, if you just download it to the flash, it won't run because system starts from the base address. So we also need to build the bootloader project. It's this one. So we can make a boot, build up this one. And you can also take a look at what bootloader is doing. It's very similar to the application. There will be some initialization for the com in order to be able to print something from your art. And then after that, it's just a function to jump to the application. That's it. So we can take a look at what this function is doing. So we have a jumper.cfile.cfile. So this function will jump to application. We'll first do arrays of the internal SRAM just to make sure we don't leave anything for the application before jumping to it. Okay, then after that, we get a rom start address of the application and then set MSP and then just call this function. So this is a function pointer pointing to this address and then we'll jump to it. That's it. So this is how bootloader jump to application works. Okay, so then we can compile this one and program the binary to the board. For QBiddy, we can do the programming from QBiddy programmer. We choose this one. The binary of bootloader is inside debug folder. So we program this one to base address of user flash. And then we can also program. So at this moment, we can take a look at the print message. So let's clear the screen. I do a reset of the board. Now you can see this is the print coming from the bootloader. And bootloader is trying to jump to application. However, at this moment, if you take a look of the location where application supposed to have, this is not the, this is still some data. Okay, we can clean the flash first and then we program this binary. Okay, and then we go back to this area. So this is, there's nothing for the application right now. That means, although the bootloader tried to jump to application, but there's no application program on board yet. So it won't run. Then we can program the binary of the application is here. Program this one, but this time we need to make sure we program to address that offset of 8200. So then start programming. Okay, and this time we can reset the board. Now application is running. So this is how the bootloader jumping to application can work. Okay, so that's it for this end zone. This end zone should be quite simple. So in this end zone, you have seen how to have a standalone loader separated from the main application. What kind of changes is needed in the application project to adapt to the new memory layout. How to jump from the loader to main application.