 Welcome back! If you have reached to this video, I believe you have understood how to use ST's ecosystem and QBWB Bluetooth examples. In this video, we're going to extend our previous Bluetooth examples by trying a feature called Over-the-Air Firmware Update. Before we start, please check these prerequisites. Until now, when you modified the BLE example, you have updated this firmware application by using a physical connection, a connection between your nuclear board and your computer. Instead, it is possible to update the firmware by using wireless communication, and this is known as the Over-the-Air Firmware Update. In this video, we are going to use Bluetooth communication to demonstrate a firmware update. The linker script is a text file made up of a series of linker directives that tells the linker where the available memory is and how it should be used. When using the STM30Q IDE, this LD file is the linker script. If you open this, you'll see various texts and directives. For instance, the word origin specifies the start address of a memory. In this case, the linker script in the BLD heart rate example stated that the start address of the flash memory is 0x0800000, which means this heart rate example is going to be programmed in the start address. While using the Qube IDE, use the Build Analyzer tab to check where the firmware is occupied and how big it is. After resetting the microcontroller, each CPU runs separate applications. For instance, the code size of the BLD heart rate example is 17 kilobytes, and this example didn't have the OTA feature. This application code is programmed at the beginning of the flash memory, and CPU1 runs this code. Additionally, CPU2 executes the BLD stack and the FOSS, which stands for firmware upgrade services. Both applications are programmed at a dedicated flash address when using this 1 megabyte microcontroller. When the OTA feature is available on the STM32WB side, the memory allocation is slightly different. Instead of occupying the beginning of the flash memory, the user firmware application is located in the address 0x08007000. Now, a separate application called the OTA loader will be using the beginning of the flash memory. By using the OTA, the user can independently upgrade the user application, the BLD stack, or the FOSS. The OTA update procedure follows a client server architecture, where the STM32WB acts as an OTA server. The OTA is initiated by an external client, such as the mobile STBLE sensor app, or the STM32Q monitor RF. To use the OTA, there are three requirements from the STM32WB side. First, the OTA loader application must be programmed in the first six sectors in the flash memory. Second, in the user application, the OTA reboot characteristic is required. Additionally, a method to verify a valid user application can be used. From these examples, the user application stores a magic keyword inside the magic keyword address, which is 0x08007140. The OTA loader will use this address and read the magic keyword to verify whether a valid user application is downloaded. Lastly, a free area of the flash memory. This area acts as a temporary storage when a new firmware image is transferred from the client. I'll explain more about these in the next couple of slides. The OTA loader allows an OTA client to upgrade the firmware image. Compared to previous Bluetooth examples, CPU1 boots to the OTA loader after a reset. The CPU1 is running the OTA loader. The OTA loader will jump to the user application if there's no OTA request and the user application is valid. The OTA loader will check the magic number to determine this. If not, the OTA loader starts advertising to nearby OTA client devices for a Bluetooth connection. The OTA loader has the OTA service and characteristics. This BLE service is used to download a new firmware image. Now, we are going to download this OTA loader inside the STM32WB microcontroller. Before we start, use the STM32Q programmer to erase the flash memory. You shouldn't remove every sector of the flash because you want to leave the fuzz and the wireless stack. Then, navigate to this project directory to flash the OTA loader. I'll use a duplicated copy of the project with the STM32Q IDE for this demonstration. Take a moment to erase the flash memory. Let's build the BLE OTA example, which is the OTA loader application. I'm going to import the project to STM32Q IDE. While waiting for the project to be built, here are the key points. First, if you check the linker script, the OTA loader will be occupying the beginning of the flash memory, where that address is hex 0x0800000. Plus, the first six sectors will be used for the OTA loader. I have marked function names with an italic typeface and parentheses. Since we have erased the flash memory, the user application doesn't exist, and the magic keyword in the user application is invalid. Before the program counter points the main function, the system init function is executed first. This function calls the boot mode check to check what type of reboot request was created. I'll place breakpoints to check this. The debugging has started, and the OTA loader is now downloaded inside the beginning of the flash memory. If you don't have any breakpoints like now, the debugger will be halted from the beginning of the main function like this. The call stack on the left top corner also shows that the debugger is halted at the beginning of the main function. Let me place two breakpoints and start debugging. You can find aforementioned functions inside drivers, cmsys, system stm32wbxx.c file, the system init function, boot mode check function, and the check firmware app validity function. I'll place one breakpoint inside the boot mode check function like this. The reboot reason is stored at the beginning of the SRAM, which is hex address 0x2000000. The boot mode check function will read that SRAM data to check the request type. The debugger has halted at the first breakpoint. The call stack says the system init function is called after a reset. The next breakpoint will be placed inside the main function of the OTA loader. As the second breakpoint shows, the main function is called since there is no valid user application. The user application was erased using the queue programmer. As a result, the check firmware app validity function notices that the address of the magic keyword is outside the flash memory's address, meaning the user application is invalid. So, the OTA loader verified that the user application is invalid. Now, the main function is called and initializes the OTA service. Next, the delete sectors function is called for freeing the flash memory. After this, the STM32WB starts advertising waiting for an OTA client to be connected. We have now made the STM32WB advertise. Let's use the mobile app to transfer a firmware image. You'll notice an example file that has this underscore OTA written in the end. We are going to build two OTA applications, the heart rate OTA example and the P2P OTA example. Navigate to this directory and build it using the STM32Q IDE. OTA examples have a different linker script. Since the OTA loader is using the first six sectors of the flash memory, the user application starts in address 0x0 800 7000. This can be found from the flash memory starting address. Next, two OTA regions are defined. According to this linker script, the OTA region's address is fixed to 0x0 800 7140. Here, it has the address of the magic keyword value variable, and this is identical to the OTA region end. In the app.blc source file, you can find variables using these OTA regions. By using the STM32Q programmer, if you read memory 0x0 800 7140, the value is 0x0 800 B584. This is the address where the magic keyword is stored. Now back to the mobile app. Once it is successfully built, navigate to this directory where you can find the firmware image. Copy these to your mobile device and let's connect the smartphone to the STM32WB. After this step, we are ready to transfer this firmware image using Bluetooth. Turn on your BLE sensor app and scan nearby OTA server devices. Also, take a close look at six bytes of the Bluetooth MAC address, especially the first byte. A portable battery is connected to the nuclear board to show that this is a wireless demo. After selecting a nearby OTA server, select a firmware image you want to transfer. I'll select the heart rate OTA example. The address written in the app is the offset address by adding hex 0x7000 to the flash memory start address, which is 0x0 800 0 0 0. This becomes 0x0 800 7000 as expected. I'll fast forward the transferring part for now. Transferring the image is complete. The STM32WB now runs a heart rate OTA example. Let's connect this device. Intentionally, the OTA loader increments the MAC address so that the client is ensured to launch a new discovering phase to detect new services. You have done a great job following this exercise. Let me summarize what just happened. You have downloaded the OTA loader at the beginning of the flash memory after erasing the user application. So the OTA loader advertised BLE packets and your mobile phone was connected and transferred a firmware image, which was the heart rate OTA example. This heart rate OTA example has the proper magic keyword inside the flash memory, and this has the OTA reboot characteristic as well. As a result, the OTA loader jumps to the heart rate OTA application after receiving the firmware image. So what is this OTA reboot characteristic? The reboot characteristic is used for the user application to jump to the OTA loader. Both the heart rate OTA example and the P2P server OTA example have this reboot characteristic included. If the reboot characteristic is available on the user application side, the STBLE sensor app can discover this and provide an additional menu to run the OTA loader. Then let's use that menu to replace the heart rate example to a P2P server example. Press the OTA config menu on the bottom. Using the OTA reboot characteristic, the user application reboots and runs the OTA loader. The OTA loader has deleted the existing heart rate OTA example. It is now advertising and the mobile app can be connected to transfer a different firmware image. I'll send the P2P server OTA example this time. You have now replaced the firmware. Let's see whether the user application is working. To summarize, due to the OTA reboot characteristic, a reset was triggered to run the OTA loader. Then the OTA loader deleted the existing heart rate OTA example. The new P2P server OTA example was transferred into the free area of the flash memory. After this transmission, the P2P server OTA example was executed. The last exercise session will address how to modify a non-OTA example to an OTA example. This is a recap of the requirements. Since we want to modify the BLE example, let's focus on the second item. First, you have to modify the linker script. You need to change the start address of the flash memory. Also, the OTA tag section needs to be added to place the magic keyword-related variables. As a recap, we have compared the linker script. If you have modified the non-OTA example, the linker script will look like this, and you can check the variables located inside the correct memory area. Next, the OTA reboot characteristic has to be added. The UUID of this characteristic notifying the reboot request, the increased size of the characteristic, modifying the advertising packet, triggering the reset should be implemented. When handling the reboot request, this writes the reboot request type inside the beginning of SRAM 1, which is hex address 0x2000000. After this, the STM32WB readsets, and the OT loader calls the boot mode check function to read that request type. Lastly, the code related to the vector table offset register has to be removed. This is because the OT loader already sets the correct values for the vector table offset register. After removing this part, you have successfully created a BLE firmware with the OTA feature included. Great job following this video app. For more information about the OTA, please check these items, and I will be looking forward to seeing you in other sessions. Thank you.