app version string in partition image

[phatpaul]

I need the ability to tag my application image with a name and version string.

Does the ESP32 app image file (*.bin) have any metadata embedded?

Otherwise, I'm thinking of declaring (in the app code) a const char[] which is rooted at a fixed address. Then retrieve that string from a fixed offset in the app image partition and display it in this table.
It's dirty and won't work on an app which doesn't declare that string... Do I need a special linker file or is there some directive I can put in the code to force the string to be put at a fixed address?

• Should be able to read the version info from a xxx-ota.bin file (compiled esp-idf project output). I.e. the file is selected in a web-based OTA updater and ready to send to ESP32. The javascript can read and display the version info before sending it to the ESP32.
• Should be able to read it from the running ESP32 code. Should be able to read it from all partitions, not just the running one. It would allow me to populate the "App Version" column in the partition info table here- https://github.com/chmorgan/esphttpd-freertos/pull/9
• Should be determinable if the version info exists or not- to avoid displaying junk if not exist.

[ESP_Angus]

Hi phatpaul,

What ESP-IDF version are you using?

A very similar feature has been added in ESP-IDF v3.3 (currently in beta):
https://docs.espressif.com/projects/esp ... escription
https://docs.espressif.com/projects/esp ... app_desc_t

The app_desc_t structure itself is not in the docs (will see if we can fix this), but can be found here:
https://github.com/espressif/esp-idf/bl ... rmat.h#L94

[phatpaul]

Thanks ESP_Angus this looks interesting. But I'm currently on stable 3.1.3. So is this structure not present in my builds? (I don't see any obvious version strings when looking at the .bin file in a hex-editor)

Where is this structure physically located? Is it stored in the image itself (in the .bin file)? or is it stored in the ota_data partition?
Is it stored in a determinable location so I could access from a script operating on the raw .bin file?
How does one set the strings in esp_app_desc? Ideally some #define statements somewhere.
I found the answers to those questions here:
https://github.com/espressif/esp-idf/bl ... system.rst

Application version is stored in :cpp:class:`esp_app_desc_t` structure. It is located in DROM sector and has a fixed offset from the beginning of the binary file. The structure is located after :cpp:class:`esp_image_header_t` and :cpp:class:`esp_image_segment_header_t` structures. The field version has string type and max length 32 chars.

To set version in your project manually you need to set PROJECT_VER variable in your project Makefile/CMakeLists.txt:

For Make build system: in application Makefile put PROJECT_VER = "0.1.0.1" before including project.mk
For Cmake build system: in application CMakeLists.txt put set(PROJECT_VER "0.1.0.1") before including project.cmake.

If PROJECT_VER variable is not set in project Makefile/CMakeLists.txt then it will be retrieved from either $(PROJECT_PATH)/version.txt file (if present) else using git command git describe. If neither is available then PROJECT_VER will be set to "1". Application can make use of this by calling :cpp:func:`esp_ota_get_app_description` or :cpp:func:`esp_ota_get_partition_description` functions.

So how do I determine what is the exact fixed offset from the beginning of the binary file?

I'll experiment with the 3.3 branch to determine if this fits my needs. Then I'll evaluate the difficulty of back-porting it to my stable code.

[phatpaul]

Ok, I hacked the esp_app_desc_t into my 3.1.3 branch and it seems to work.

I see from the hex editor my PROJECT_VER text appearing at address 0x00000030.

This checks out since there are 2 structs before the esp_app_desc_t.
esp_image_header_t is 24 bytes,
esp_image_segment_header_t is 8 bytes.

So info struct starts at offset 24+8 = 32 = 0x20.
PROJECT_VER is at offset +16 inside the info struct.

So I'll start using this mapping in hopes that it stays the same in future stable releases.

[ESP_Angus]

Ok, I hacked the esp_app_desc_t into my 3.1.3 branch and it seems to work.

So I'll start using this mapping in hopes that it stays the same in future stable releases.

Yes, this is likely to stay the same (from v3.3 onwards) in order to allow newer firmwares to read verison information from older firmwares.

I'm glad your hacked up IDF v3.1.3 is working well. Hopefully after the v3.3 stable release is out you'll have a chance to update.