ESP32 Forum

Hi,

I have started to work on ESP-IDF RTOS SDK and found that it has been released with 1.0 version as well.

I have also found that there are some changes related to OTA APIs as well.

So, please provide me sample configuration and code to implement firmware update code into existing ESP32-idf RTOS SDK.

Is this a similar question to the one you just asked?

http://esp32.com/viewtopic.php?f=13&t=623

If so, the response might be of value. The docs are behind the functions and the request is to read what docs what we have, even if they are just the header files and then come back with focused questions. As time passes, better docs will become available just through osmosis.

Hi,

Thanks for Reply. But, it seems that you are also on same page as me to look for firmware update API documentation and how to use that.

Have you found any sample code or have you developed sample code for firmware update?

Please let me know if anyone has developed that type of sample code for firmware update.

By reading the header file, it seems to me:

1. We call esp_ota_begin() to start the beginning of an OTA image write
2. We receive data that is part of the image
3. We call esp_ota_write() to write the data we just read
4. Go back to 2 while there is more of the image to receive over the network
5. We call esp_ota_end() to flag the end of the OTA image write
6. We call esp_ota_set_boot_partition() to specify which partition will be booted on next reboot

For the sake of a working discussion (and the above may not be accurate), lets assume this to be correct and see what questions come from contemplating and testing the above.

Hi,

Thanks for quick reply.

Let me check code and understand it. I will let you know if need any help w.r.t. OTA update into ESP32.

@kolban: indeed, this is how these functions are supposed to work.

@ESP_igrr

With those mechanics understood, now let us think of the nature of "file" to transfer to write into the OTA partition. Imagine I am using the ESP-IDF make system. This produces a binary which I flash to 0x10000 (if memory serves me). Now in the OTA world, if I produce Version1 of my app, when I produce Version2, do I need to "compile" it to a different address space or (as I may guess) the act of mapping the flash partition "puts it" in the correct address space for the CPU?

Q: Do I have to prepare my application any different?

Next comes the question of "what" do I send? If I run a compile, I get a "app.elf" file which then gets "munged" through a tool (which I don't understand) to produce an "app.bin". I am "guessing" that I send the "app.bin" ... but is the data that is written to the OTA partition the "whole" file or part of the file or something else?

Q: Do I send the "app.bin" over the network?

The binaries that you feed to the OTA subsystem are the exact same binaries that you normally feed into esptool.py to flash using the serial port. For 'real' OTA, this is a bit barebones (eg there's no checking to see if the firmware supports the hardware it's flashed on, no encryption support etc) so we're thinking of adding a layer on top of it that can have embedded metadata and encryption and stuff, making it a bit more robust.

ESP_Sprite wrote: so we're thinking of adding a layer on top of it that can have embedded metadata and encryption and stuff, making it a bit more robust.

Sounds good. Definitely need encryption and/or signature verification.

kolban wrote:the act of mapping the flash partition "puts it" in the correct address space for the CPU?

Q: Do I have to prepare my application any different?

Q: Do I send the "app.bin" over the network?

Yes

No, other than supporting ota functions and using a suitable partition table

Data transfer is up to user. You could send it over IR to the rmt peripheral for fun.