 Ok, now the last part, here is the HL settings, first part is very useful option in case that you want to reach very low power consumption and it's the option to set all three pins as an analog. On some devices, mainly the F devices, are all three pins set as the floating input. These inputs can really increase your consumption. We will look on this during one hands on, how behave the unconfigured or the floating input pin. Then if you want to be sure that your consumption will be stable and very low, you can set here this option to set all an unused pin as an analog. This means all these gay pins will be set as an analog input and in this mode the pins have very low consumption. But be careful, in case that we select this option, then all unused pin will be set also as an analog. Problem is that between these pins is also the J-Tech, which is defaultly set into this mode. And if you set these pins like this, then you will lost the contact with your debugger and you need to use the connect underset in your IDE or you need to use the stealing utility to erase your macro controller. Then you not happened that we lost the contact with debugger. Here in the debug, you need here select the SWD or the J-Tech depends which board do you have. And it will reserve for you the J-Tech pins. And then you never lost contact with your debugger. But in case that we not using the set all free pins as an analog, we don't need to care about this. And definitely I don't want to now test this option. Now the last part, which I have here is the enable the full assert. What this means? The full assert is the macro. It's usually all functions checking the input parameters inside the HL library. Then if we enable this use full assert, then in case that the input parameter is wrong and the macros inside the HL function will detect this, they will go immediately into the full assert fault handler. If we open our project, the assert fault handler is usually in main. It's here and you are notified that something is wrong. Some input parameters are out of the ranges inside the assert failed macro. Then you can put here for example vile or some checking function to check if your function parameter is really okay or really wrong. I think we can very simple test this. I here create new option, for example setting 5, setting 6. I enable the full assert and now I will generate my project. I will open my project and now in the application in the main.c I have here the assert failed. Then I put here my code, which will block the complete, complete processor. I will use the vile one. I can try to force him to go into the assert failed with the simple trick. I here put the HL, the GPIO. We use the same functionality like before. We can use the toggle pin. The GPIO A, like before, and we use the GPIO pin underscore 5, it was before. Then this will always be okay because this option exists. Okay, we not now configure the pin, then we will not toggle with our light, but this is okay. This is more than us for the testing. If we go to the debug, you now know how to do this also for the different IDEs. I can here put the pay point by clicking or double clicking on the left side of this line. And I can run my code. Sorry, it was entering the debugger again. I can run my code. This is my big point here. And you can see I never reached this big point because the parameter is okay. All the parameters are okay. But if I here put the input parameter, which is obviously wrong, you can see there is the value, then it seems I can put here, for example, the pin 17, because the pin 1 is on the bit 0, pin 2 is on the bit 1, pin 3 is on the bit 2. And I here put the 01 and I try to create my pin 17, which doesn't exist. I will check what this will do if I will enter some false state or not. And you can see the parameter was wrong. I am into the assert failed function. Then this is useful in case that you want to be sure that your input parameter are in the correct range. Okay.