Dear all,
Based on the OTA Demo mentioned in the link below, it requires the firmware to be updated through serial interface initially. Is it a mandatory step to initially update the firmware.
https://github.com/espressif/esp-idf/tr ... system/ota
If we dont update the firmware, can the default firmware be used to perform OTA. If yes is there any link of how the OTA Process happens in this scenario.
Thanks in advance
Over The Air Update feature
-
Vader_Mester
- Posts: 300
- Joined: Tue Dec 05, 2017 8:28 pm
- Location: Hungary
- Contact:
Re: Over The Air Update feature
I just read through the readme, and yes you need serial, but only to load the OTA example software on the ESP32.
As it mentions, you need to erase the flash using the "make erase_flash flash" command before typing "make flash", to flash the OTA example to the ESP.
After serial flashing, the OTA example will run, and starts to look for the established HTTP server (as described in the example), and starts the OTA process through WIFI.
Just follow the instructions, it will take you there.
(I might try it out myself today, to see how well it performs)
As it mentions, you need to erase the flash using the "make erase_flash flash" command before typing "make flash", to flash the OTA example to the ESP.
After serial flashing, the OTA example will run, and starts to look for the established HTTP server (as described in the example), and starts the OTA process through WIFI.
Just follow the instructions, it will take you there.
(I might try it out myself today, to see how well it performs)
Code: Select all
task_t coffeeTask()
{
while(atWork){
if(!xStreamBufferIsEmpty(mug)){
coffeeDrink(mug);
} else {
xTaskCreate(sBrew, "brew", 9000, &mug, 1, NULL);
xSemaphoreTake(sCoffeeRdy, portMAX_DELAY);
}
}
vTaskDelete(NULL);
}Re: Over The Air Update feature
Dear Vader Mester,Vader_Mester wrote:I just read through the readme, and yes you need serial, but only to load the OTA example software on the ESP32.
As it mentions, you need to erase the flash using the "make erase_flash flash" command before typing "make flash", to flash the OTA example to the ESP.
After serial flashing, the OTA example will run, and starts to look for the established HTTP server (as described in the example), and starts the OTA process through WIFI.
Just follow the instructions, it will take you there.
(I might try it out myself today, to see how well it performs)
Thank you for your time in replying to my query. So does it mean the factory image in esp32 doesnt have an OTA Upgrade capability and
does the default image (factory image) have only factory image and no OTA Partition, Due to which we have to initially program the flash with OTA Partitions for enabling the OTA update.
Thanks in advance.
-
Vader_Mester
- Posts: 300
- Joined: Tue Dec 05, 2017 8:28 pm
- Location: Hungary
- Contact:
Re: Over The Air Update feature
Yes this is the case. It's just a feature you can include in the project.FCT_IOT wrote: Dear Vader Mester,
Thank you for your time in replying to my query. So does it mean the factory image in esp32 doesnt have an OTA Upgrade capability and
does the default image (factory image) have only factory image and no OTA Partition, Due to which we have to initially program the flash with OTA Partitions for enabling the OTA update.
Thanks in advance.
As you can see the OTA example recommends you to flash the ESP32 with he OTA example, which do nothing else but OTA update the ESP32. It's like every other software.
By the way, if you follow the instructions, it will actually download to the ESP, the Hello_world example, so when you or the OTA example resets the ESP, the Hello_world example starts running, which you can see from MONITOR tool ("make monitor" after you flashed the ESP).
So this OTA example is nothing but a demo, and is not on the ESP32 by default.
For example how would a factory ESP now your Wifi SSID, password, IP address of the OTA server etc
... technology is not yet that advance, but seeing the efforts of the Espressif team we will be eventually be there 
Code: Select all
task_t coffeeTask()
{
while(atWork){
if(!xStreamBufferIsEmpty(mug)){
coffeeDrink(mug);
} else {
xTaskCreate(sBrew, "brew", 9000, &mug, 1, NULL);
xSemaphoreTake(sCoffeeRdy, portMAX_DELAY);
}
}
vTaskDelete(NULL);
}Re: Over The Air Update feature
Dear Vader_Mester,Vader_Mester wrote:Yes this is the case. It's just a feature you can include in the project.FCT_IOT wrote: Dear Vader Mester,
Thank you for your time in replying to my query. So does it mean the factory image in esp32 doesnt have an OTA Upgrade capability and
does the default image (factory image) have only factory image and no OTA Partition, Due to which we have to initially program the flash with OTA Partitions for enabling the OTA update.
Thanks in advance.
As you can see the OTA example recommends you to flash the ESP32 with he OTA example, which do nothing else but OTA update the ESP32. It's like every other software.
By the way, if you follow the instructions, it will actually download to the ESP, the Hello_world example, so when you or the OTA example resets the ESP, the Hello_world example starts running, which you can see from MONITOR tool ("make monitor" after you flashed the ESP).
So this OTA example is nothing but a demo, and is not on the ESP32 by default.
For example how would a factory ESP now your Wifi SSID, password, IP address of the OTA server etc
Thank you for the reply. When i read through the OTA Example, i too had the same opinion. I just wanted some clarity.
Thank you.
Re: Over The Air Update feature
A supplementary question, if I may... To avoid reinventing the wheel (I have plenty of new code of my own to write), are there any more sophisticated examples of ESP32 OTA available? The little demo in the IDE examples seems to be a single shot thing which blindly downloads a new image from a server, flashes it and reboots into it. In a real OTA context, the booted image would need to be aware of its version number, would need to check with the server to see if there was a more up-to-date version and, if there was, it would need to do another OTA download and flash. It should also do some simple check-summing to verify that the download has been successful and there needs to be some provision for rolling back if the new image fails to boot properly...
There are quite a few wheels to be invented there - and I'm getting old and grey for that sort of low-level coding! Anyone seen a genuine, real-word OTA example?
TIA
There are quite a few wheels to be invented there - and I'm getting old and grey for that sort of low-level coding! Anyone seen a genuine, real-word OTA example?
TIA
-
Vader_Mester
- Posts: 300
- Joined: Tue Dec 05, 2017 8:28 pm
- Location: Hungary
- Contact:
Re: Over The Air Update feature
Hi martinB,
The wheel is already invented. It's called OTA server polling. Your mobile phones do that actually, by looking for updates themselves.
Since all servers can be different, with sever thousand different authentication processes, there is no stantard example for them.
The provided OTA example is a good example, the functions in there should be called from your application, which does the OTA functions, but making sure you know what to download is a different type of code.
The following procedure can be followed:
If you have a server dedicated to storing OTA update binaries, you can do the following.
- The server should have a value storing the actual firmware version of the stored binary, which can be read via a simple request from the ESP. If a new binary is on the server ready to be sent to the ESP devices, it should update the firmware version.
- The ESP device polls the server at selected intervals (for example every day), the server send the firmware version to the ESP, which compares it to it's own version. If there is a mismatch, then the ESP now knows that it can do an OTA.
(Note: It's not advies to set the server to notify the ESP devices, becaue it is not secure, so the ESP device should contact the server, so the actual IP address of the ESP device stays roughly secure and can acount for dynamic IP changes (since the server IP is in most times don't change).
- If the application of the ESP involves a lot of parallel things to happen, I suggest that if you detect that a new firmware is available, before doing the OTA, store a flag on your NVS data space (on flash), which will indicate an update must be done. After this flag is set, then reboot the ESP. Since the flag is on the flash, it stays there after reboot.
On startup,(before any serious tasking of your application start), ask the ESP to read this flag from the flash. Is the flag is set, then start OTA, delete the flag, and reboot the ESP. It will reboot into the new firmware, checks again for the flag, but now it's deleted so the ESP know the firmware is up-to-date, and proceeds running the application.
- It should be noted, that if the OTA runs on an error, it should not delete the flag set in the NVS, rather store the number of tries, with the flag,so your app can read it, and say after 3 attemps, it will no longer do the OTA update, but go back to the factory application, and send a notification to the server that the update failed, so you (as the owner of the server) will know that something is not OK.
There are tons of other ways of course, which is chosen by the user, and sadly, you must write it.
By the way, the components of the above procedure is already given in the APIs, and ESP-IDF, you just need put this stuff together with some "C glue"
Vader[BEN]
The wheel is already invented. It's called OTA server polling. Your mobile phones do that actually, by looking for updates themselves.
Since all servers can be different, with sever thousand different authentication processes, there is no stantard example for them.
The provided OTA example is a good example, the functions in there should be called from your application, which does the OTA functions, but making sure you know what to download is a different type of code.
The following procedure can be followed:
If you have a server dedicated to storing OTA update binaries, you can do the following.
- The server should have a value storing the actual firmware version of the stored binary, which can be read via a simple request from the ESP. If a new binary is on the server ready to be sent to the ESP devices, it should update the firmware version.
- The ESP device polls the server at selected intervals (for example every day), the server send the firmware version to the ESP, which compares it to it's own version. If there is a mismatch, then the ESP now knows that it can do an OTA.
(Note: It's not advies to set the server to notify the ESP devices, becaue it is not secure, so the ESP device should contact the server, so the actual IP address of the ESP device stays roughly secure and can acount for dynamic IP changes (since the server IP is in most times don't change).
- If the application of the ESP involves a lot of parallel things to happen, I suggest that if you detect that a new firmware is available, before doing the OTA, store a flag on your NVS data space (on flash), which will indicate an update must be done. After this flag is set, then reboot the ESP. Since the flag is on the flash, it stays there after reboot.
On startup,(before any serious tasking of your application start), ask the ESP to read this flag from the flash. Is the flag is set, then start OTA, delete the flag, and reboot the ESP. It will reboot into the new firmware, checks again for the flag, but now it's deleted so the ESP know the firmware is up-to-date, and proceeds running the application.
- It should be noted, that if the OTA runs on an error, it should not delete the flag set in the NVS, rather store the number of tries, with the flag,so your app can read it, and say after 3 attemps, it will no longer do the OTA update, but go back to the factory application, and send a notification to the server that the update failed, so you (as the owner of the server) will know that something is not OK.
There are tons of other ways of course, which is chosen by the user, and sadly, you must write it.
By the way, the components of the above procedure is already given in the APIs, and ESP-IDF, you just need put this stuff together with some "C glue"
Vader[BEN]
Code: Select all
task_t coffeeTask()
{
while(atWork){
if(!xStreamBufferIsEmpty(mug)){
coffeeDrink(mug);
} else {
xTaskCreate(sBrew, "brew", 9000, &mug, 1, NULL);
xSemaphoreTake(sCoffeeRdy, portMAX_DELAY);
}
}
vTaskDelete(NULL);
}Re: Over The Air Update feature
Thanks for that - I will roll my sleeves up - still a fair few wheels to reinvent, I fear!
First I need to tidy up my code - it's reaching the point where I'm having difficulty understanding it!
Martin
First I need to tidy up my code - it's reaching the point where I'm having difficulty understanding it!
Martin
Re: Over The Air Update feature
Hello,
I'm working on OTA with ESP32( ubuntu 16.04 ) but I have some problems. Did you solve the problems ? And if you write an example, can I take it ?
Thanks
I'm working on OTA with ESP32( ubuntu 16.04 ) but I have some problems. Did you solve the problems ? And if you write an example, can I take it ?
Thanks
-
DannyBackx
- Posts: 33
- Joined: Wed Sep 19, 2018 7:17 pm
Re: Over The Air Update feature
I have code that appears to work, it does strange things which I seek an explanation for.
You can check its source in https://sourceforge.net/p/espalarm/svnc ... in/Ota.cpp .
I can basically trigger an OTA by sending the app an MQTT message like this :
% mosquitto_pub -t /alarm/node/waskot -m ota://192.168.1.101/esp/keypad.bin
Questions :
- when I turn off the flashing code (just run the download) it completes in something like a second.
With the flashing code, it appears to take a couple of minutes.
Inserting debug code appears to cause strangeness though.
Is it normal that the flash takes a couple of minutes ?
- Sometimes the flash/reboot causes the gdb session to trigger, and quickly spit out thousands of lines.
Can this be explained ?
- Other remarks about the approach or my code ?
Thanks,
Danny
You can check its source in https://sourceforge.net/p/espalarm/svnc ... in/Ota.cpp .
I can basically trigger an OTA by sending the app an MQTT message like this :
% mosquitto_pub -t /alarm/node/waskot -m ota://192.168.1.101/esp/keypad.bin
Questions :
- when I turn off the flashing code (just run the download) it completes in something like a second.
With the flashing code, it appears to take a couple of minutes.
Inserting debug code appears to cause strangeness though.
Is it normal that the flash takes a couple of minutes ?
- Sometimes the flash/reboot causes the gdb session to trigger, and quickly spit out thousands of lines.
Can this be explained ?
- Other remarks about the approach or my code ?
Thanks,
Danny
Who is online
Users browsing this forum: stdenits and 84 guests