 This is a second hand zone for the bootloader. So on top of the simple one, we will add some protections. In this hand zone, we're going to reuse the same application from the previous one. There's no need to make any change. But for the bootloader, we're going to enhance it by adding some protections. That includes the right protection of bootloader flash pages. And we are going to define a secure user memory area to protect the whole bootloader. And then in the bootloader code, before jumping to the application, we will activate the protection of secure user memory area. Then when the application is running, we can run some tests from the application trying to access the address within the secure user memory area and see what's the effect. In terms of hardware boards and the software tools to be required, that's exactly the same as the previous one. So I assume you have everything in hand. Regarding the zip file of the project to be used for this hand zone, so still the same one for application. If you have that built from the previous hand zone, you just keep using the same. No need to change anything. And for the bootloader, we're going to use this one. G0BeerProp.zip. So this is a project of the bootloader with protections. Ready? Let's go. Now we start the second hand zone for the bootloader. We will keep using the same application as the first one. There's no need to change anything on the application. But we will make a little bit of improvement of the bootloader. We're going to add some protections to the bootloader. The first thing is to have the secure user memory to be used to protect the bootloader. And the project that we are going to use is this one. So G0 underscore BLProp. So still you can use the ID that you wish to have. So if we can take a look at the source code. So in may dot C, we will keep using the same function, but there will be a different implementation. This time you can see that we're using a different jumper.C5. It's not any more jumper.C. It's jumper underscore PROD.C. So the implementation becomes this piece of code. This time we're not jumping to the application directly. Instead, the code will call to a function resize in the system bootloader. This is the address of the function in the system bootloader. And that function is going to check the magic number. You need to give the right magic number. And eventually at the end, that function will also jump to the application address. But before that, it will activate the protection of the secure user memory. So right to the secure protection bit in the flash control register. So this is how this jumper will have the protection activated. And then in the C file, we have also added one more function call to activate the WRP. At this moment, I keep it disabled for a moment. We will activate it at the end. So it's a similar idea. We will activate the write protection in the code to the flash pages that is reserved for the bootloader. Actually, this could be done in the software. It can also be done in the programmer. So there's nothing special. We have already experienced the same thing for the hash page protection. In the other hands on that, we have the hash value on the flash. OK, so now we can build the project. And then in the programmer connect to the board. So first take a look at the option bite. Make sure that you don't have any write protection, no PC drop RDPs in level 0. And then we can set this secure user memory size to 1.0. That means 16 pages, which is the size reserved for the bootloader. OK, we set that. And the flash is empty. Download the program. The bootloader. This is the bootloader binary just built. So download it to the base address of user flash. And then we download the application. Same binary. Download it to 8200. So the application is running. Then we can try this test by typing 1. So this test is actually trying to access some memory address within the secure user memory area. So first one is the base address of user flash. And the other one is another address. So within this 8000 area. You can see that this will generate a hot foot. So this is the way that we can protect the bootloader from being accessed, either being read or write, or any access from the application. So once the bootloader jumps to the application, the application has no more access to the flash area that the bootloader was using. That area will be available again only after a reset. So the next time the bootloader is running, then those areas will be available again. Then let's connect to the board again and the modified option byte to set this area to zero, back to zero. And we will see what's the effect. OK, let's connect. So let's reset the board. Clear the screen. Reset the board. So we can still run the same test from the application, try to access the same two memory addresses within supposed to be the flash area where this bootloader is supposed to be using. So this time there is no more hot foot. We can read the content from those addresses. That is because we don't define any size for the secure memory. So this protection, even though the software writes to the register to activate the protection, but somehow the protected area is zero. The size is zero, so there's no nothing protected at all, actually. So now you can see how it works. Then for the write protection, I'm not going to do it. You can try it yourself. In the code, you can uncomment this line, and then the write protection will be activated in the code by default. Let's have a recap. So in this bootloader with protection hands-on, we have seen what kind of protections could be applied to ensure the immutability of the bootloader code, how to use secure as a memory on G0 to protect the bootloader area on flash, and what is the effect when protection of secure as a memory is activated in the bootloader before application is launched.