 Secure user memory, the purpose, code data and execution isolation of a secure user firmware, principle, a user flash vision executed at boot time, whatever the boot mode configuration. On the executed, the secure user part is closed and cannot be accessed anymore by any mean until the next boot. It's configured thanks option bytes, so it's a static protection, and it's supported on G0G4 family, H7, L5, and under L5, this mechanism is also called HDP. The secure memory on the G0G4 family. So it's an area located at the beginning of the flash and executed after the reset. The configuration is done thanks one option byte, sex size. There is a second one if you've got a dual bank and could be only modified in ADP level zero. So if you combine sex size with ADP level one, if you want to remove the secure memory, you have to do a regression from ADP level one to ADP level zero, which implies a flash maceras. The granularity is a flash memory page size, and this secure memory can be locked at application execution time. Then the secure memory is no more visible. You just have to write in the flash register, but I will just detail after that we can also use a services from the RSS or the system book loader. Debugger can be disabled when executed some sensitive data. So it could be really useful in ADP level one when you want to do some secret usage like authentication or decryption. So as I previously said, the secure memory could be locked thanks to services in the system book loader. The reason is that as soon as the secure port bits or is a bit in the flash control register is set to one, the secure memory becomes invisible to the whole system. So if you do it in the secure memory, then you will be in fault because even you the core can't access to continue the program. And if you are doing it after in the non-secure part, imagine a hacker managed to connect just before this, he could just stop and manage to see the contents. It's why we've got such kind of services. So if I so map the resets, then the option byte loading, this is done by hardware, then we've got code execution in the secure memory, then we will call a system boot loader services to set the secure port bit, then the secure memory becomes invisible and we jump to the application code execution. In the application code execution, we can't see what is in the secure memory. It's completely invisible. I'll just show you the flash control register, secure port bit version, and then the debugging link which is enabled. Then you can decide to disable it to do something quite secure or quite secret, I would say. Then don't forget to re-enable it to be able to connect on your target. Then the debugger become available. Now for the GZero, we've got an additional features. If you combine the boot lock with the ADP level 1, then by default the debugger will be disabled. I write a quotient because if you don't have the re-enable of the debugging link inside your code, you are an ADP level 1, but you can't connect at all on the port. Even the boot loader is not allowed. So take care. There is no way to recover from this situation. So here we've got the classical system, but imagine we've got the boot lock plus the ADP1. Then the debugging link is I would say disabled by default. Then you need to re-enable it, then the debugger become enabled. So really important, that means if you erase your chip and you don't have this re-enable of the debugger and you are in this configuration, your board is wrecked. Let's talk now about the secure memory on the STM32H7. This configuration could only be done in the secure access mode. That means when you activate the security option byte, bit, sorry, to one. The secure memory error is executed after the reset whatever the boot mode. There is one secure memory area per bank and it has the granularity of 256 bytes. The secure memory is locked thanks to services in the RSS. The secure user memory can never be accessed by the debugger or by the codex M4, in the case you are in a dual core. So the same schematics are done with G0. On the reset, we've got option byte. Here we've got the RSS boot. You can have the detail of this boot inside the reference manual. Then we've got the code execution in the secure memory. Then you need to code the RSS exit secure services. Then we jump to the application code execution and the secure memory has completely disappeared. From the debugging link point of view, the debugger is disabled during all the secure memory execution. Then you will become enabled. So here you imagine the risk. If you've got a configuration when you configure all the option bytes but have nothing in the secure memory area, then you will never jump to the application code and your debugger is also disabled. So caution also here. So in the secure access mode, to configure the secure user memory area, you need also to call a root security system services. So that means you need the execution of some firmware to be able to configure the secure memory. This is quite different from the GZero. I will have just an animation after to make you better understand this. So as I previously said, the secure user memory configuration could be removed on ADP level regression or flash bank eras. But if you eras the secure memory era and keep the option byte configured, then the debugger is disabled because you will start it on the secure memory era without any code here. So we get stuck in this vision and there is no possibility to recover. So really take care with this. Now the animation to show you how you can activate the secure memory area on the H7. First we need to have the secure access mode. So the security bit and the option byte set. Then we need to program the secure firmware in the future secure memory area because it should be here when we will start after. Then we will prepare the parameters for the sec area start. So the value we want to put in the option byte but it's not our code that will will configure those option bytes. We will just path those parameters to the services of the RSS which name is reset and initialize secure error. On that stone there is a reset and you get this configuration now. That means you are booting on the RSS which select which user memory, secure user memory should be launched, then it will jump to the user memory and remember about the access. Debugging access is only possible outside the secure user memory. Same thing for the Cortex M4, the second core when you are in dual core. Of course the core M7 could access to anything. Let's move now to the secure memory on the L5. So here it's closely linked to the trust zone configuration but I want to have a couple of words here. So the secure hide protection also called HDP. On close this part cannot be accessed anymore by any means until the next boot. It's located at the start of the flash watermark based secure error. To sum up what is a flash watermark based secure error I would say on the L5 we've got a Cortex M33 with trust zone and when this trust zone is activated you've got two words inside your chip the secure one and the non-secure one. Here that means the HDP will be inside the secure word and at the beginning of the flash. It's configured thanks to option byte so an hdp activation and then the hdp end which is the end address because the beginning is the beginning of the secure part. Across all the family I think it was clear it was on the L5 or the version h7 g0 and g4 on specific device. So you have to check for each one the reference where it's possible on it. I think that's all for the secure memory now we can go on with on zone.