Hi,@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,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,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.
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.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.
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.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.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.
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?