Hi everyone,
My question in this topic is about the OTA update logic itself, I have my code running inside ESP32-WROOM-32E and the update itself is running smoothly.
My goal is to implement a logic in such a way that the device won’t perform an OTA update to a state that it can’t perform OTA again.
I thought that using the rollback functions of the esp_https_ota library was the solution, but it seems that once the ESP32 boots from the new partition (the one that you downloaded the new version to) the former program is erased from flash, therefore you cannot go back to it. Can anyone give me some suggestions on how I can go on with this idea?
Thanks!
Does anyone have any ideas about this?
Thank you.
Hi everyone,
So, after reading some documentation over here (Over The Air Updates (OTA) - ESP32 - — ESP-IDF Programming Guide latest documentation) I was finally able to make some progress on this matter, anyway, there are still some problems I’d like some help with.
At the rollback process part (Over The Air Updates (OTA) - ESP32 - — ESP-IDF Programming Guide latest documentation) it is mentioned that when you perform OTA, the first boot with the new partition is monitored, therefore it receives the ESP_OTA_IMG_PENDING_VERIFY flag and in case of reboot before calling the esp_ota_mark_app_valid_cancel_rollback() function the application would rollback to the previous working version.
Unfortunately, that is not what is happening, instead, after the OTA update, both images are shown as valid, so the rollback never occurs.
Did somebody encounter the same problem?
Thanks!
Hi,
The documentation states that :
If the CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE option is set, and a reset occurs without calling either function then the application is rolled back.
The default setting certainly is that this option is not set. I didn’t look at how it can be enabled (I am using PlatformIO and some ESP32 build settings are harder to find under this platforms).
Regards,
To enable this flag in PlatformIO, you need to go to platformio.ini and add
build_flags =
-D CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE=1
Hi @gkfernandes I’m trying to achieve the same goal “My goal is to implement a logic in such a way that the device won’t perform an OTA update to a state that it can’t perform OTA again.”, where you able to figure this out completely?
In particular, in my case I’m storing FW on SPIFFS, then load from that, but if FW is not bootable, crashed the way I cannot handle it I want it to rollback to previously loaded FW.
Were you able to figure this out eventually?
Hello @didenkos ,
Welcome do the Platformio community!
It’s been a while since I worked with this part of the project, so there’s been some hiccups here and there that I had to solve, I’ll list a few of them so you can check if it applies to your case.
Otherwise use esp_ota_mark_app_invalid_rollback_and_reboot(), that should reboot with your last valid firmware loaded into the MCU.
If the FW is not bootable, it won’t go through any of these functions and should reboot to your previously valid FW.
Thank you for the reply, I really appreciate it!
Yes, I did try both “esp_ota_mark_app_valid_cancel_rollback() and esp_ota_erase_last_boot_partition()” and they seam work Ok, no issues there.
But when I’m testing FW that cannot even start and reach the point where I can say this FW is Ok or not, it does not roll back to previous one (even though it is available) and roll back enabled, it keep trying to boot up from a new one, which I intentionally made bad one.
In other words, " If the FW is not bootable, it won’t go through any of these functions and should reboot to your previously valid FW." - I cannot reproduce this scenario. Any hints?
Sergey
@gkfernandes Hi Gustavo
Thank you for the reply, I really appreciate it!
Yes, I did try both “esp_ota_mark_app_valid_cancel_rollback() and esp_ota_erase_last_boot_partition()” and they seam work Ok, no issues there.
But when I’m testing FW that cannot even start and reach the point where I can say this FW is Ok or not, it does not roll back to previous one (even though it is available) and roll back enabled, it keep trying to boot up from a new one, which I intentionally made bad one.
In other words, " If the FW is not bootable, it won’t go through any of these functions and should reboot to your previously valid FW." - I cannot reproduce this scenario. Any hints?
Sergey