 In the next example, I will introduce you a USB DFU class, so this is for download firmware update, universal class which is intended for software update of the device which are already in the field or also for the development. This class in current way can use one of the two drivers. There is a bit older version connected to DFU update 2. We will also use it using this demonstration and this version use dedicated driver from ST, STTube 30, which we will be able to see a bit later. There is also a bit newer version connected to new tool from ST, so called Q-Programmer, which is using different driver which is made on VIN USB. You are able to see DFU class also in embedded ST system bootloader, but the capabilities of this class or of this implementation there is limited. As you for sure know, there is no possibility to change the content of the system memory, so the bootloader there is fixed and with the rising needs for the security there are also or different functionality there may be need to implement your own bootloader. So for example USB 1 using the DFU class. So in our example we will create a project where part of the user flash will be used for the bootloader itself and the second part will be updated using the USB. What is also one of the advantage with user bootloader is that you may use other kind of protection for example the readout protection which I will show you a bit later and with the system bootloader you won't be able to use the readout protection at all. So again we will start with QPMX, still the F446 nuclear board and like before we will use precise clock source so bypass high speed external, go to USB OTG and full speed and choose device only. Additionally we will go to middleware and choose the download favor update, so DFU. Here we will also use the PC 13 for the button, later on in the program using the button we will choose whether we want to update or go to the new program we loaded using the DFU. So this is all in the pinout table, now we will set again the clock so the input frequency is 8 MHz and for example 168 is good for us. But here with DFU there is a bit more configuration we need to cover in the middleware layer. So we can see here some class parameter settings and two most important are the DFU up default address and DFU media interface. So first is the address of the application which we want to load. So on some address we will start our second part of code with the program which is intended to be updated. So we need to choose probably according to some sector address to make some estimation how many memory we need for the bootloader itself and the rest we can dedicate for the application. And that we also need to show in the media interface which is part of the descriptor. And it's describing the device we are using. So here is the starting address of our microcontroller and after that we are highlighting all the part of flash inside of the microcontroller we are using. So with different family this descriptor will have different shape. And after that there are the letters which are standing for the size of the amount of memory. So here it's K16K of flash and the A or G is about the permission which the user application will get. So let's go back to the presentation. And here we see how it will be in our case. This is but that's not exactly what I want to show you now. So the default address sector to 8000 and internal flash descriptor. But more important is part of the application note about about the letters and their meaning. So byte kilo mega that is quite obvious. But more important and not so straightforward visible is are the digit behind the multipliers. And here you can see that A is sent only for readable beef erasable. All permissions are for G. So if you need to get more information or look for it again there is the application note 0 424. And on page 72 you can find all this information. But back to our example. So on the default address we will use the sector two. So 8 million 8000. And as we can see the granularity of STM32F446 is four sectors of each by 16 K. First two we will use for the bootloader that is 164 K sector. And afterward after that 3128 K sector of flash. So only first two sectors will be read only. And for the other the DFU host will have the possibility to read write and erase. So let's put it into the cube. So the starting address 8 million 8000. And after that we see that 8 million is correct. Then we have two 16 K sectors with read only. After that will be two sectors with 16 K. We already can read write erase. After that one sector of 64 K with read write erase. After that and the last types of sector are 3128 K with all the permission. And that's all we have. So with this shape we can continue. But also we need to be careful that this is true only for our STM32F446. With different family maybe different. Last thing we have here and maybe also important for us is the transfer size. With higher number will be faster transfer. We need to be careful that DFU is using only endpoint zero. So the granularity of the transfers is still 64 even with the high speed. But it will be faster grouping if we use higher number. But also with higher number is growing the need for the RAM dedicated for this buffer. So it's a trade-off between the speed and dedicated RAM to this purpose. Next thing we need to do here is also the interrupt. Because inside of the DFU driver is used the whole delay. So we need to have smaller priority for USB than for the SysTik. So we don't get locked. And with these changes we are free to build. And so some name. So DFU up. Again we choose the through studio and we increase bit the heap as we use quite a big buffer for the memory. And we can generate a project. So let's open the project and take a look what was generated for us. Again the main. And the important part is DFU interface fail. On the start we can see the flash description string which is passed to PC and showing the information about connected device. And here are the important function for entering or accessing the memory. So erase write read and also the status. For now it's empty. Again it may be device dependent. You have the content how to fill it in the presentation. But very easy and convenient way how to find the correct code is also to use the example in the cube repository. So in this example we will use them. So let's go to the repository. So I have here installed all the packages. So let's go to F4 project STM32446. Well applications USB device. And here is DFU standalone. So example which already contains all the or at least similar code. So in the source we will see the main and DFU flash that see where the code will be visible. So here we again see descriptor in the similar way. And prefilled function. So let's use it in such way. So first during the initialization we need to unlock the flash. During the init we want to look it again for erase. There is bit more code also for the write. Read is quite simple but still it would take some time to figure out how to correctly fill. Then we have the status. So again use the same. And we can see there is a bit more function or bit more variables used in the code. So for example the sectors which are entered. So we need to add two more functions mainly due to the fact that the applications still want to be universal. So get sector function and get bank in our single bank device. It's quite simple but it's here due to the universality and compatibility with dual bank devices. So we need also to define these two functions. So let's put them into the not provide function declaration. And we should also miss in the header file the sector numbers. Let's take a look if the red of file. Yes. So also we add these sector numbers. And now the microcontroller will be able to show to the host available sector and rewrite the code which is in the user section of our program now. But still we want to be able not only to update the code but also to jump into the code we loaded into the microcontroller. Ok. Flash programming time flash race time. That is something I missed to define here. So yes. We did that also. So we can take a look into the main that see of our demo. And here will be visible the function which is used for jumping to another part of code. So in the function here the button is check. And if the button is pressed and the address where we are planning to jump contain the code we change the address to this one. Normally this is fine according to our documentation before this jump also interrupt interrupt should be clean and cystic cystic should be disabled. Because some troubles could be reached during this but it's more or less only to be 100 in line with the documentation. And for the simplification we will use only the function as it here in the example. So I will again use the example code and put it in the main. Here I want to use the begin and section because I don't want to initialize the USB if there should be jump to the user code. But instead of the BSP function we will use the regular read of the GPIO GPIO C GPIO pin 13. Okay. There were also some definition which we need to use. So let's copy them also only some of them and this should be now completed. So let's try if I haven't missed anything. Yes, I did. Okay. There is also the definition of the P function in the main.h. So not here. Okay. I found it in my presentation to do not lose the time. So just avoid. And now we have it completely. So let's go into the debug code and connect to PC. So now it's running and we can observe connected devices. And here we see our microcontroller in DFU mode. So now we are connected. But how to use it from the PC? I told you that now there exist two options. First one is a DFU demo tool which is available on ST sites. That one we will use a bit later on. Second one is the Q programmer quite new option. So you have it in the presentation presentation attachment or you can find it also on the ST websites. So I will go directly to the installation folder. Now there is available version 3.0.6. And here there are not only the documentation and drivers but two most important files are the file manager which is creating DFU files out of the hex file and demo application itself. So let's run the demo and we can see that we have connected device. And here on the internal flash we see the sectors and what we are able to do with the sectors. So the permission we have. So on first two which are allocated to the book loader itself we can only read. On the other we have the full access. So now we have the application in the microcontroller but nothing to be loaded. So for this purpose we will again create a very simple program with QPMX. So a new one again F446ZE. And here in this project we will only enable the LEDs and the LEDs are PB0, PB14 and PB7. And that's it. We can just generate the code with some names. And of course Atolic. So let's open the project. I will close this one so it's not mixing with my project. And now this is the LED toggling program which will be loaded into the microcontroller memory with the DFU. So using the USB. And we need to make two changes here to make it run from different than the default 8 million address. So first is the linker file. So we will highlight here that the program is starting from the address 8 million 8 thousand. And second important thing is that we are as we are on different address we need also to move the vector table. So on M4 core which is inside of the F446 there is the option to relocate the Vitor. So not exactly here we want in the source file. So we can see here that Vitor is flash base and offset. And we know that the flash base is smooth to address 8 million 8 thousand. So these are the changes which are necessary to run the project from different address. Now we just add our simple functionality here. So in it everything and now in the while loop we add the LED toggling. So it's PB0 and for example PB14 and in between we put some delay. So that's it but we want to roll it into the microcontroller using the debug. But we need to get the hex file as an output from the build. So for various ideas this option is different. So how to do it? In the Atolic we will go to C C++ build settings to settings. And in other we see the output format. So we want to get Intel hex as output from the build. So okay and let's build one more time. And here we see that hex file was created. Okay so we have our hex file and now we need to push it to the microcontroller itself using the DFU. So let's return back to the installation folder with the DFU tools. So here we will go to the file manager which will create as such windows with option. And we want to generate a DFU file from a hex. So let's continue. And so first we need to choose the hex file. So where I have it? USB exam plus toggle debug. And here is it. And generate here the DFU file. So successfully created. So we can close and return back to the demo tool. So now we are here. We choose to update and go to debug and here is the DFU file. We want to have it also with verification and go for upgrade. So everything went successfully. And now we can see after the reset the LED are toggling and the device is not connected because before the USB was initialized we jumped to the user code. But if you reset with holding the blue button the application is again available and we are able to one more time upload the data. So here we are now more or less in the similar functionality like with the system bootloader. So now we can demonstrate the functionality of this solution also with readout protection. So we can use the ST link and go to the option bytes. Or for demonstration purpose we will first erase the complete chip. Disconnect now I need to load again the main application. So close the LED and use the application with USB DFU. Okay. So now I should be again able to see but it's cannot enter the second part of the code. So the user application is not loaded there as I expected. So let's go to the ST link utility and enable the readout protection one. After this move you won't be able to work with the system bootloader anymore. So now with system bootloader you would not be able to load the code. But the readout protection is not disabling the access to the flash only the debug possibilities and system memory possibilities. So now the debug cannot read the memory content but using our bootloader we will be able to access there. So can reset. Okay. One more thing now as we enabled the readout protection and so debug access to the microcontroller is disabled and ST link on the nuclear board is accessing using the debugger the microcontroller. We need to disconnect the ST link otherwise it will be stacked and cannot run. So right now we will remove the connectors on CN4. So now the debug is not active and cannot access the microcontroller but the application is running. So now the microcontroller with the readout protection one and still we are able to upgrade. Again with the button we are able to jump to the bootloader but using the simple reset. The device disappear in the program and LEDs are blinking. So this is all I wanted to show you in this demo. For sure more can be achieved using this tool. Also you may be used that using system bootloader you are able to access more types of memory. For example also the option by Vine Temp programmable. This is also possible using the user bootloader but bit more programming is needed then. Also external memories connected to the microcontroller can be accessed using this way. There is a lot of option and nice results can be achieved using this one.