Setting CONFIG_BOOTLOADER option
Setting CONFIG_BOOTLOADER option
We're working on an OTA component via a potentially very slow connection (GPRS or IoT-NP). We're using esp_ota_begin(), esp_ota_write_with_offset() and esp_ota_end(). The arduino-esp32 version is 4.2. The build environment is Visual Micro.
Everything works as expected. However as the last piece we would like to enable automatic rollback if the upgrade crashes. For this we need to set the CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE option. Is there an easy way to set this option? It doesn't seems like the sdkconfig.defaults route works in the Arduino setup but not sure...
Any help is appreciated...
Everything works as expected. However as the last piece we would like to enable automatic rollback if the upgrade crashes. For this we need to set the CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE option. Is there an easy way to set this option? It doesn't seems like the sdkconfig.defaults route works in the Arduino setup but not sure...
Any help is appreciated...
-
lbernstone
- Posts: 1132
- Joined: Mon Jul 22, 2019 3:20 pm
Re: Setting CONFIG_BOOTLOADER option
The CONFIG_ features are compiled into the libraries included in arduino-esp32. You would need to compile you own libraries with the lib-builder if you want to enable this. I don't know your exact method of update, but it seems like what you want is already there. That CONFIG option is used if you want to fully control the update process, and decide for yourself if the image is valid. If turned off, however, it will automatically mark the OTA invalid and rollback if the new image is invalid. You can test this by adding corruption into a .bin file and uploading manually with esptool.
Re: Setting CONFIG_BOOTLOADER option
Hi, nice to see you here. Thanks for the quick response!
The issue we're trying to address is not a potentially bad image. We were planning to account for that via a SHA signature but from what you say, we might actually be able to save ourselves the trouble.
What we are trying to implement is the rare case when a legitimate image crashes on a particular machine be it due to a bug, a weird configuration or any number of other combinations. The application is a rural well monitoring system and any failure in the field could be rather expensive.
From what we understand is that this is how the workflow is supposed to work when the CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE flag is set:
Best,
Gregor
The issue we're trying to address is not a potentially bad image. We were planning to account for that via a SHA signature but from what you say, we might actually be able to save ourselves the trouble.
What we are trying to implement is the rare case when a legitimate image crashes on a particular machine be it due to a bug, a weird configuration or any number of other combinations. The application is a rural well monitoring system and any failure in the field could be rather expensive.
From what we understand is that this is how the workflow is supposed to work when the CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE flag is set:
- Down load the image and save it with esp_ota_begin() and esp_ota_write()/esp_ota_write_with_offset()
- Finalize the upgrade with esp_ota_end() and esp_ota_set_boot_partition()
- Reboot the system
- If the system crashes during reboot and testing, the bootloader will automaticially roll back to the previous image. (There is also a manual option to roll back)
Best,
Gregor
-
lbernstone
- Posts: 1132
- Joined: Mon Jul 22, 2019 3:20 pm
Re: Setting CONFIG_BOOTLOADER option
I post docker containers for release versions on dockerhub. While large (~500MB), they make it simple to build libraries for a quick change like this.
https://hub.docker.com/r/lbernstone/esp ... b-builder/
https://hub.docker.com/r/lbernstone/esp ... b-builder/
Re: Setting CONFIG_BOOTLOADER option
Thanks, that really appreciate and should close the last big gap in functionality between ESP32 Arduino and ESP-IDF. I wasn't too fa,iliar with Docker but it seems a great solution for this.
Unfortunately the Docker command line doesn't work. You're sure you made the packet public?
Also, the URL is referencing esp32s2. I thought that was the single core MCU. Are the bootloaders identical for both?
Thanks again for all the hard work!
Best...
Unfortunately the Docker command line doesn't work. You're sure you made the packet public?
Code: Select all
C:\dev\docker>docker pull lbernstone/esp32-arduino-lib-builder:esp32s2
Error response from daemon: manifest for lbernstone/esp32-arduino-lib-builder:esp32s2 not found: manifest unknown: manifest unknownThanks again for all the hard work!
Best...
Re: Setting CONFIG_BOOTLOADER option
NM, ignore the last message. However the correct docker tag is (not esp32s2).
This was really a great help and again, very much appreciated.
Gregor
Code: Select all
docker pull lbernstone/esp32-arduino-lib-builder:idf-master_20210403This was really a great help and again, very much appreciated.
Gregor
Re: Setting CONFIG_BOOTLOADER option
Hi,
Sorry for digging out an old thread, but it's the best one I can find. My goal is to use APP_ROLLBACK_ENABLE under an Arduino framework. I know I lack this option in the bootloader. I also discovered that if I build a custom bootloader from esp-idf framework it will break compatibility with Arduino's pre-compiled libraries (like NVS self-clearing mentioned here).
I want to avoid rebuilding the libraries though, as the project I contribute have a public sourcecode. Having "special" libraries would work only for me, so this approach won't be any good, unfortunately.
As that ROLLBACK feature is entirely in bootloader code, I wonder if I could recreate a binary bootloader which would have it incorporated, but apart from this was completely compatible with specific Arduino's build? Arduino authors must have built it somehow, didn't they?
I just hope I wan't the first person to try such approach as I'm really not fluent in C/C++ buid universums.
Sorry for digging out an old thread, but it's the best one I can find. My goal is to use APP_ROLLBACK_ENABLE under an Arduino framework. I know I lack this option in the bootloader. I also discovered that if I build a custom bootloader from esp-idf framework it will break compatibility with Arduino's pre-compiled libraries (like NVS self-clearing mentioned here).
I want to avoid rebuilding the libraries though, as the project I contribute have a public sourcecode. Having "special" libraries would work only for me, so this approach won't be any good, unfortunately.
As that ROLLBACK feature is entirely in bootloader code, I wonder if I could recreate a binary bootloader which would have it incorporated, but apart from this was completely compatible with specific Arduino's build? Arduino authors must have built it somehow, didn't they?
I just hope I wan't the first person to try such approach as I'm really not fluent in C/C++ buid universums.
-
lbernstone
- Posts: 1132
- Joined: Mon Jul 22, 2019 3:20 pm
Re: Setting CONFIG_BOOTLOADER option
The arduino repo files are built using the lib-builder. APP_ROLLBACK is enabled by default, and does work if, for instance, a firmware gets corrupted.
Re: Setting CONFIG_BOOTLOADER option
I forgot to mention my framework is 2.0.6 (with native ESP-IDF version 4.4.3). OTA works, but new firmware partitions receive "VALID" status instantly on boot, while I would prefer "PENDING_VERIFY".
-
lbernstone
- Posts: 1132
- Joined: Mon Jul 22, 2019 3:20 pm
Re: Setting CONFIG_BOOTLOADER option
You can set the state to whatever you want after you use the arduino-esp32 updater. Otherwise you have to roll your own.
There are a couple weak functions placed in initArduino that allow you to override the verify behavior if that is what you are looking for.
There are a couple weak functions placed in initArduino that allow you to override the verify behavior if that is what you are looking for.
Who is online
Users browsing this forum: PerplexityBot, Qwantbot and 3 guests