 So let's get started. So OTA is actually an application which is provided as a source in the WB-Cube package. So it's ready to be modified and customized by anyone. It resides at the very bottom of the flash and it occupies about 24 kilobyte. And there are three main purposes to update the application or just a part of it. So it can be, for example, a configuration data that you want to change. And of course, it's also possible to upgrade the RF stack when needed. So there are two ways to do this. Currently, you can use the STBLE sensor. This app is on GitHub, also in source. So you can carry out the firmware upgrade with your phone. A second way to do this is with another STM32WB. So to make it work, you flash the OTA clients with so-called transparent mode. And this communicates with the CUBE Monitor RF running on your computer. And CUBE Monitor RF can do many different things. It can access the ACI commands of the Bluetooth stack. But in this particular use case, we are only interested in the OTA. So let's have a look more technically on how it works. It's important to understand the memory mapping and the interactions between the individual firmware. So WB is a dual core with a single bank flash. So the area dedicated for M0, M0 plus, is secured, which means the user core, the M4 cannot read it, cannot delete it, cannot write to this. So the user section starts from the bottom and ends at the security barrier. So at the bottom, we have the OTA application. So this is the firmware executed after reset. And the first thing it does, it searches if there is a valid application and it searches for the OTA request. If it finds no OTA request, it will be simply bypassed. So it jumps to the application and then the application is executed. Now what is an OTA request? OTA request is a way for the user app to call the OTA. And that's done in a very simple way. The OTA request, which is just a word in SRAM, the first memory address of SRAM, that's where we put the OTA request and then a system reset is generated. So after reset, the OTA boots, it checks the command because the SRAM retains the value between resets and it proceeds accordingly. So this is how it's done. So let's imagine a scenario when actually there is an OTA request. So when this happens, the OTA application will initialize the Bluetooth and it will start advertising. And it's now ready to be connected by the OTA client, which can be your phone, which can be any other device. OTA is actually a Bluetooth proprietary service, in this particular use case. So it's a service with three characteristics. There is a characteristics for defining the base address where we want to flash the data. There is a characteristic for the exchange of the raw binary data. And once all the data have been transferred, then there is an indication back to the OTA client saying that the upload finished successfully. Okay, let's talk about the application first. So what are the necessary steps to integrate the OTA into your user application? So most obviously it needs to be linked above the OTA. But from the BLE perspective, it's necessary to do two things. For the custom BLE service, we need to add a special characteristic, which is called an OTA reboot characteristic. And this is integrated into any BLE service you can imagine. The second thing is changing the advertising. So let's talk about these two things separately. So this is a simple example. Let's imagine the user application is a heart rate. So it's a very simple Bluetooth service, which is actually adopted by Bluetooth SICK. It has two characteristics. One compulsory one is the measurement. So this is the actual heart rate value, which is sent to the phone or your wrist health meter. Then there is a characteristic that specifies the position of the sensor on your body. And now what's important, if we want an OTA to integrate OTA into this service, we add an OTA reboot request characteristic. So in there, when the client writes into this characteristic, he can request the OTA application, which will generate a reset afterwards. We can also specify here which area in the flash will be erased. So because we need to free space when we need to upgrade, then here we can do this. We can select which sector, which is the beginning sector of flash and how many sectors we want to delete to free upspace for the new version of the application. So regarding the advertising, the OTA capability is also advertised, and this is done by a special proprietary advertising structure. This is described in the STBLE BlueST protocol. So in there, there is a feature mask, which is indicating what the device is capable of. So according to this standard, there are many bit fields related to sensors, but what interests us the most is the OTA reboot bit. So this is how the phone immediately knows from the advertising content that this device is capable of OTA. So let's have a look at the flow of the OTA. So let's keep in mind the heart rate supporting OTA. When the phone sees the advertising content, he already knows it will support OTA. When it connects, it will perform the service and characteristic discovery. It finds the OTA reboot characteristic. So it writes to it, and immediately a reset is generated. So the OTA application boots, it will erase the area in the flash, which we tell it to erase. After that, it will start advertising and the phone can connect again. Then there is the process of exchanging the data of the raw binary and storing that into the flash. And once this is done, the target sends an indication that the upload has finished. Another reset is generated, OTA reboot. It finds a valid application, so it's bypassed. That's the end. So before we go to the first hands-on, just a few words about the firmware which is running on the M0 Plus. So it's obviously the RF stacks. It can be Bluetooth, can be Thread, can be ZigBee. But it can also be FUS, the firmware upgrade services. So these stacks are provided by ST in an encrypted form. So there must be a firmware which decrypts it and install it. And this is the purpose of FUS. So in fact, when you want to upgrade the wireless stack, there are three options. You can use a system bootloader, USB or UART. You can use an OTA. And you can use also a JTAG. The first, it's actually a process which has two steps. So firstly, we need to store the encrypted binary in the flash. And then we need a code, a firmware, which calls the FUS services. And the M0 Plus will do the rest. So this firmware can again be a system bootloader. It can be OTA. It can be a custom application downloaded by JTAG.