ESP32 Forum

Hi,

A short question as I have not found the answer yet in the documentation: is there a way to determine the version of the secondary boot loader that was used to start an application from within that same application ?

It will print on the terminal on boot if you are hooked up with a USB cable.

John A

edit: oops! I guess I didn't read your question very well.

You could calculate a checksum/hash of the bootloader partition and compare it to known values or check for the version string at known addresses (which will change depending on the version) or append the version to the end of the bootloader binary. But no I don't think any function is provided to do it.

Hi,

In reply to both earlier replies, this will do it: esp_get_idf_version(). I found out that that is how the bootloader reports the version on the UART during boot.

No because when you call that in the app it is going to give you the version the app was compiled with and could be different from the version the bootloader was compiled with.

Ah, it is a bit of a chameleon then.

Never mind: in the mean time I have found a solution for my problem for which getting the bootloader version may have helped.

My problem was the following:

• We have two versions of our application software: my, recent, version and an earlier prototype version that was made for proof of concept purposes.
• My recent version uses a much more extended customised partition table which the modern bootloader can deal with effortlessly.
• The prototype version uses a much older bootloader version that can't handle the new partition table at startup and therefore fails to start the updated application.
• The bootloader.bin in the older version is +/- 14kByte whereas the new one is about 24kByte.
• The old version was entirely written in assembly, the modern version was done in "C".
• We have +/- a hundred units out in the wild running the old bootloader/application version which as time goes on we would like to OTA upgrade to the new version.
• Unfortunately that does not work so easily: for the new version I absolutely need the new partition table and the new bootloader that can handle the new partition table at startup.
• Equally: standard OTA upgrades do not provide the possibility to upgrade the partition table or the bootloader.

In the end the solution is maybe not the most elegant one but it is relatively simple:

• Both the new bootloader and the new partition BIN files are considerably larger than the old ones.
• So when the system reboots after an OTA update to the new version it is still using the old partition table and bootloader and starts the new version as expected.
• The first thing the new version then does is to check whether or not the expected new partition table or the bootloader is present.
• If either or both is/are not present, checked by means of looking for empty flash sections: i.e: not filled with expected data beyond the range of the old partition table and/or bootloader, the existing partition and bootloader section(s) are erased.
• Copies of the required BIN files, integrated into the new application, are then written into the relevant flash locations.

I have tested it really thoroughly and it sure works a treat!

Sounds fine as long as the risk of brick if power is lost during bootloader/partition writing is acceptable.

The risk is acceptable as the units are permanently battery powered. The only time it could go wrong is that when the battery just comes below the brownout level when we happen to be writing the new partition and/or bootloader sections.

That is not entirely impossible but extremely unlikely as the units are supposed to run for a number of years on the available battery capacity and OTA updates should be few and far between.

Sorry for the slow reply. I'd like to check a couple of details about the setup you have, Zingemneire:

Zingemneire wrote: ↑

Fri Nov 09, 2018 11:50 am

• My recent version uses a much more extended customised partition table which the modern bootloader can deal with effortlessly.
• The prototype version uses a much older bootloader version that can't handle the new partition table at startup and therefore fails to start the updated application.
• The bootloader.bin in the older version is +/- 14kByte whereas the new one is about 24kByte.
• The old version was entirely written in assembly, the modern version was done in "C".

Are you talking about the ESP-IDF bootloader in both cases? There was no version of the ESP-IDF bootloader that was entirely written in assembly. Or is this a fully custom bootloader?

Because ESP-IDF doesn't support OTA updating of the bootloader, we try to maintain backwards compatibility for the bootloader back to IDF v1.0. For compatibility with bootloaders pre-IDF v2.1 you have to enable an option in the app configuration, but then the app should work with both older and newer bootloaders:
https://docs.espressif.com/projects/esp ... OOTLOADERS

The prototype version uses a much older bootloader version that can't handle the new partition table at startup and therefore fails to start the updated application.

The only situation I can think of where an ESP-IDF bootloader should fail to load the partition table is if the offset is moved from the default 0x8000 (and the older bootloader is looking at the default offset). Otherwise, the partition table format hasn't changed. If this is an unmodified ESP-IDF bootloader, you can be more specific about the failure?

As discussed already, it is possible for a device to "OTA" flash a new bootloader if you're not worried about the possibility of a power failure or a crash during the update (which will brick the device). But in general we've tried to make this unnecessary so that older bootloaders can continue to be used.

Hi ESP_Angus,

I am not 100% sure that the older bootloader was written in assembly.
It is an assumption because I can only find ".s" type code in folder bootloader support in the build directory so that may be generated code.
For the new bootloader used in ESP-IDF v3.1 I can find the original C code for it under components->bootloader and bootloader support.
The binaries for both bootloader versions are radically different: the old one is +/-14kByte while the new one is +/- 23 kByte.

To the best of my knowledge both the old and the new version are standard versions.

For the new one I am absolutely certain as it is rebuilt every time I do a complete project build and I most certainly never changed a single letter in the original. I used TortoiseGit to get the ESP-IDF and it still shows it to be identical to what was extracted from Github.

I can't be as certain for the old bootloader version as I did not create that binary myself but I would be very surprised if changes were made to it. As far as I know it was simply used "as is".

As to the older version crashing when it reads the customised partition table: that is a fact. The new bootloader can handle it, the older one does not. It is odd though as the customization part of it is just the declaration of a few extra partitions after the ota_1 partition ( see below ).



If you want to know exactly what version the old bootloader is I can send you a copy of the assembly code I can find in the "bootloader-support" directory.