Video, how to ot updates happen in the ESP 32. In this video, we will learn about the use case of ot updates in the ESP 32. Then, we will learn about the partition tables and bootloader of the ESP 32. Finally, we will learn the OTA update mechanism in the ESP 32. A fantastic feature of any Wi Fi enabled microcontroller, like the ESP 32 is the possibility of using the same life a feature to flash a new program. This will eliminate the need for a physical connection between the device and the PC.

So, implementing the OT update feature in an ESP 32 board will be extremely useful, especially if you are into product development. Just imagine that you manage a company which makes smart thermostats and more than 10,000 devices are on the field. Let's say that you found a security vulnerability in your device and want to patch this bug with an update on all your customers devices. In this case, it is not practical to ask the customer to update by connecting the thermostat to a PC manually. Furthermore, your company may have to employ technicians. To help customers with this update.

The simple solution is to implement an OTA update feature before the product reaches the market. Then, we can simply update all our devices over the air using Wi Fi. Isn't that simple. In practice, it is not that simple as we can't simply overwrite the current firmware with a security update. There are two reasons for this. The first reason is that the current firmware is actually the one running and responsible for performing the network retrieval of data.

Thus, while we override with new firmware, the network retrieval instruct might get corrupted and will result in an incomplete update that can disable OTF functionality all together. The second problem is that something could go wrong with the data transmission, and we would end up with a partial update, which likely would not boot. So what is the workaround to these hurdles, the solution is to load our new code in a completely separate but equally sized area of flash memory. If the download of the new code completes successfully, only then use the new partition as the boot partition. Before we look at how this is implemented in ESP 32, let's learn what happens inside the flash memory when a new code is flashed via the USB cable. Whenever a new code is flashed to the ESP 32 the code is stored inside the flash memory that is attached to the SPI bus of the ESP 30 To chip.

The flash memory is a non volatile memory, unlike the ram inside the ESP 32 chip. Thus, even when the ESP 32 is switched off, the code will be saved in the flash memory. The sparkfun ESP 32 thing has a flash memory of size four megabytes. A single ESP 32 s flash can contain multiple apps, as well as many different kinds of data like calibration, data, file systems, parameters, storage, etc. As all these data are present in single flash memory, the ESP 32 chip needs a map to locate the position of different data sets. This is done in ESP 32 through a concept called partition tables.

It is just like the Index page of a big book, but with more details of the content it's pointing to the partition table starts at Default offset of 32,768 bytes, it has a size of 3072 bytes with a maximum of 95 distinct table entries. Each table entry is 32 bytes long does all the 95 increase together take 3040 bytes. The last 32 bytes are MDF checksum used for checking the integrity of the partition table. If you want to know more about the partition tables, please visit the link in the resources. When the ESP 32 board is powered up, initially the control is given to 4096 bytes position in the flash memory called the boot loader. there is possibility of the boot loader is to select the correct partition to boot based on the partition table, then load this code to ram of the ESP 32 chip.

And finally, trust For the memory management to the memory management unit inside the ESP 32 chip. This is how a new code is accessed from the flash memory and executed on the ESP 32. Now to implement ot update without failure, we need a minimum of two ot partitions in a flash memory as discussed earlier in this video. By default, the ESP 32 uses single factor app with no ot a partition table. You can see the details of this partition table here. The NBS partition is a non volatile storage partition, which consists of the boot loader and partition table.

The fi underscore in it consists of default configuration parameters for all wired and wireless communication in the ESP 32. Finally, the factory partition consists of the current code which is flashed when the factory app to ot a definition mode is enabled in the ESP 32. The factory partition is split into three partitions of equal size, namely factory ot underscore zero, and ot underscore one. In the partition table. You can also see an OT a data partition. This partition points the boot loader to select the correct ot a partition to boot the code from using a boot flag.

If this partition is empty, the code inside the factory partition is executed by default. Thus, let's take the thermostat example again. The current code which is buggy is running in the factory partition of the flash memory of the thermostat. When I sent a new code where our Wi Fi to the flash memory, the code will first be saved in ot underscore zero partition. Now a code integrity check will be done in the OT a partition to confirm whether the code is used. Or not.

Later, the OTS data partition data will be updated to point the boot loader to use the OT underscore partition as the boot partition. instead of the default factory partition is by any chance the code in ot underscore zero partition faces some errors. The ESP 32 will automatically roll back to use the default factory partition code by resetting the boot flag. Let's say a few months later, your company decided to add a new feature like Alexa integration to the thermostat. This time when you send the update code via Wi Fi, it will be written into ot underscore one partition and the OT data partition will point the boot loader to this partition, rather than ot underscore zero by setting the bulk flag. In effect, the flash memory will have the latest code, the security update code and the initial factory firmware.

Code. Even though ot updates are necessary for IoT applications, the need to store the previous code introduces a memory disadvantage in the ESP 32. This is where creating custom partition tables will help. By properly defining and configuring the flash memory based on your application, you will save a lot of memory. Thus, we must take this factor into our design considerations before implementing the OTF feature in a project summary. In this video, we have covered the following topics.

Why implement RTA programming in the ESP 32 partition tables and boot loader in the ESP 32 and the OT update mechanism in the ESP 32. In the next video, we will look at how to implement a basic OTF feature to the ESP 32