Provide sample to update firmware into ESP32

[aschweiz]

We've been trying to get OTA updates work too and have succeeded.
You may find our blog post useful: https://blog.classycode.com/over-the-ai ... .yujyiq29c

Feedback welcome

cheers,
Andreas

[Ritesh]

@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?

Hi,

I have also have same concern regarding OTA firmware update as right now only single image is generated after compiling ESP32-idf RTOS sample app.

Please let me know if you get any informations or any flow regarding how to create OTA firmware update file and how to flash firmware through OTA which will be more beneficial for me in my current project.

[Ritesh]

We've been trying to get OTA updates work too and have succeeded.
You may find our blog post useful: https://blog.classycode.com/over-the-ai ... .yujyiq29c

Feedback welcome

cheers,
Andreas

Hi,

Thanks for providing link.

I will look OTA update section from above link provided and will let you know if need any further help regarding firmware update from my side.

[Ritesh]

Hi,

I want to do firmware update using following ways from ESP32-idf RTOS SDK based on dual OTA partitions created.

1) First of all, provide server link with configurations using AP mode.

2) Start to download complete firmware from server configured in which one binary which contains ESP firmware + other slave devices firmware which is connected with ESP over UART.

3) Once binary will be downloaded successfully, I will create one parser based on firmware received and will update other connected slave devices and finally start to update ESP32 firmware.

4) so, Process will first check from which location firmware is running and then based on current firmware location, firmware will be flashed into another location and will be validated based on firmware and checksum calculated.

5) Once firmware update process has been validated then it will try to reboot ESP32 module and will boot it from updated location.

So, please let me know if anyone has did this type process and updated firmware into ESP32 module then provide me sample algorithm with example to me ASAP.

Let me know if need any further information from my side.

[Ritesh]

Hi,

Does anyone has any idea or sample code to download firmware file from server and flash it into both OTA locations once firmware will be downloaded successfully without any issue like steps which I have mentioned in previous post?

Please let me know if anyone has tried it like ESP8266.

[Ritesh]

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,

I have created one sample application in which I am getting firmware image using web socket and storing that image into other than OTA locations.

After that, we have created 2 OTA partitions using make menuconfig command which are OTA_0 at 0x110000 and OTA_1at 0x210000 locations.

And we have created OTA based firmware update application like steps you provided 1) OTA begin 2) write OTA data 3) End OTA and then set boot partition to boot from. But, there are also some other tasks as well as timers are already running in parellel apart from firmware update task.

Does it will create any problem like panic or illegal instruction type of issue while all timers and other tasks are running in parellel to firmware update OTA task as we are facing this type of issue while updating image from default location to OTA_0 partition.

So, I have disabled all other tasks and timers and it was working fine without any issue.

So, do you have idea for this type issue or its known issue?

Please let me know your feedback or suggestions for this..

[ESP_Angus]

Does it will create any problem like panic or illegal instruction type of issue while all timers and other tasks are running in parellel to firmware update OTA task as we are facing this type of issue while updating image from default location to OTA_0 partition.

There are no known issues of this kind. There is a restriction, which is that while writing to flash the flash cache must be disabled, so tasks on both CPUs are suspended and interrupts (except for those marked as running from IRAM only via ESP_INTR_FLAG_IRAM) are disabled. This should be handled automatically, provided that no interrupt handlers marked with ESP_INTR_FLAG_IRAM are calling into non-IRAM code.

Because of this restriction, you should expect the possibility that while writing to flash interrupts and tasks may be delayed by up to tens of milliseconds at a time. If you have interrupts that need servicing faster than this, mark them (and any functions they call) with IRAM_ATTR and flag them ESP_INTR_FLAG_IRAM when allocating the interrupt handler.

It's hard to give any more specific feedback without seeing your code or details of the crashes. Perhaps you can narrow it down to a single hardware feature or task?

[Ritesh]

Does it will create any problem like panic or illegal instruction type of issue while all timers and other tasks are running in parellel to firmware update OTA task as we are facing this type of issue while updating image from default location to OTA_0 partition.

There are no known issues of this kind. There is a restriction, which is that while writing to flash the flash cache must be disabled, so tasks on both CPUs are suspended and interrupts (except for those marked as running from IRAM only via ESP_INTR_FLAG_IRAM) are disabled. This should be handled automatically, provided that no interrupt handlers marked with ESP_INTR_FLAG_IRAM are calling into non-IRAM code.

Because of this restriction, you should expect the possibility that while writing to flash interrupts and tasks may be delayed by up to tens of milliseconds at a time. If you have interrupts that need servicing faster than this, mark them (and any functions they call) with IRAM_ATTR and flag them ESP_INTR_FLAG_IRAM when allocating the interrupt handler.

It's hard to give any more specific feedback without seeing your code or details of the crashes. Perhaps you can narrow it down to a single hardware feature or task?

But, I have tried it with another way in which esp_ota_begin() we have called initially while starting application and we are not getting any issue like "panic or illegal instruction " even though tasks, timers and other stuffs are running.

I have also checked call of esp_ota_begin and found that tasks and timer are suspended while calling that API and again resumed once it has been finished.

Please share sample if anyone has implemented firmware update using OTA APIs.

[Wilberforce]

Does anyone know what changes are required to linking scripts for say an ota2 partition at 0x200000 ?

[ESP_igrr]

No changes required. Applications are mapped into the same memory range using Flash MMU, regardless of their location in flash.