esp_app_desc!() causing: warning: unexpected cfg condition name: esp_idf_app_compile_time_date etc.

[smithwinston]

Bug description

I had an existing project that had esp_app_desc!() in it's main.rs. After updating the esp-idf-* crates, I find I get a series of warnings for a number of cfg conditions related to esp_app_desc!:

warning: unexpected `cfg` condition name: `esp_idf_app_compile_time_date`
 --> src/main.rs:1:1
  |
1 | esp_idf_sys::esp_app_desc!();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: expected names are: `clippy`, `debug_assertions`, `doc`, `docsrs`, `doctest`, `feature`, `fmt_debug`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `rustfmt`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `ub_checks`, `unix`, and `windows`
  = note: using a cfg inside a macro will use the cfgs from the destination crate and not the ones from the defining crate
  = help: try referring to `$crate::esp_app_desc` crate for guidance on how handle this unexpected cfg
  = help: the macro `$crate::esp_app_desc` may come from an old version of the `esp_idf_sys` crate, try updating your dependency with `cargo update -p esp_idf_sys`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default
  = note: this warning originates in the macro `$crate::esp_app_desc` which comes from the expansion of the macro `esp_idf_sys::esp_app_desc` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unexpected `cfg` condition name: `esp_idf_app_reproducible_build`
 --> src/main.rs:1:1
  |
1 | esp_idf_sys::esp_app_desc!();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: using a cfg inside a macro will use the cfgs from the destination crate and not the ones from the defining crate
  = help: try referring to `$crate::esp_app_desc` crate for guidance on how handle this unexpected cfg
  = help: the macro `$crate::esp_app_desc` may come from an old version of the `esp_idf_sys` crate, try updating your dependency with `cargo update -p esp_idf_sys`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: this warning originates in the macro `$crate::esp_app_desc` which comes from the expansion of the macro `esp_idf_sys::esp_app_desc` (in Nightly builds, run with -Z macro-backtrace for more info)

... and so on.

• Would you like to work on a fix? [y/n]

This is somewhat beyond my burgeoning Rust skills!

To Reproduce

1. Run cargo generate esp-rs/esp-idf-template cargo
   1.1. Enter a test project name
   1.2. Chose esp32c6 as the MCU
   1.3. Chose Configure advanced template options
   1.4. Picked v5.3
   1.5. Picked false for the rest
2. Run cargo add esp-idf-sys
3. At the top of main.rs add: esp_idf_sys::esp_app_desc!();

Then try to build with cargo build.

I'm actually working on OTA updates and I'm seeing a runtime panic (a UTF8 error it seems) inside esp-idf-svc's ota.rs:196 where it's trying to get the version string:

        info.version
            .push_str(unsafe { from_cstr_ptr(&app_desc.version as *const _) })
            .map_err(|_| EspError::from_infallible::<ESP_ERR_INVALID_SIZE>())?;

I'm not entirely sure if this related, but it surely seems coincidental.

Expected behavior

No warnings. This compiled ok in prior versions.

Environment

• esp-idf-sys: 0.36.1
• esp-idf-svc: 0.51.0
• ESP-IDF v5.3.2
• ESP32C6 (Seeed Studio XAIO)
• macOS 15.2 (aarch64)

[smithwinston]

I believe my panic maybe well be related, it seems that since the esp_app_desc_t isn't getting created properly in the .bin, it's showing up near the end of the binary image rather than at offset 32, after esp_image_header_t and esp_image_segment_header_t. Consequentially the logic in fetch() implementation is just interpreting junk as the esp_app_desc_t.

If remove the esp_app_desc!() macro, it still builds, but I then don't find the 0.1.0 version string as I did before. What's interesting is that this project seems to be ok (I bumped esp-idf-svc to 0.51.0 just to be sure), although it doesn't have the esp_app_desc!() macro, it does have the esp_app_desc_t structure at offset 32 -- note: this project is targeting esp32s3.

If I rebuild my app for esp32s3, then I get the correct esp_app_desc_t at offset 32 (without the macro). Adding back the esp_app_desc!() macro still has the cfg error though.

EDIT: I should point out that for the esp32c6, if I comment out the part where I grab the FirmwareInfo via the call to EspFirmwareInfoLoad.fetch() then I avoid my panic and the OTA update actually succeeds. Also note that the boot messages do show the app name, version and the ESP_IDF version so it's finding it ok -- is it possible that the esp32c6 just stores this somewhere different?

[ivmarkov]

Bug description

I had an existing project that had esp_app_desc!() in it's main.rs. After updating the esp-idf-* crates, I find I get a series of warnings for a number of cfg conditions related to esp_app_desc!:

You are simply using a newer rustc and are thus hitting this new feature.

To cut the long story short, these warnings are harmless (albeit annoying). Until we fix these by properly declaring our cfgs, you might want to put !#[allow(unexpected_cfgs)] in your lib.rs/main.rs.

I believe my panic maybe well be related, it seems that since the esp_app_desc_t isn't getting created properly in the .bin, it's showing up near the end of the binary image rather than at offset 32, after esp_image_header_t and esp_image_segment_header_t. Consequentially the logic in fetch() implementation is just interpreting junk as the esp_app_desc_t.

This has nothing to do with the warnings from above, and if indeed that happens, it must be chip specific, as I'm pretty sure on the s3 and on the stock esp32 it works just fine.

I would hypothesize is that the reason for the error is that this link section has an incorrect name for the c6 (and maybe other riscvs?) and there, it must be something else.

Essentially, it must match whatever link section is used in the ESP-IDF code for the same definition (the one in ESP-IDF is with a "weak" linkage attr definition, so we override it essentially).

The weird thing is, in ESP-IDF I see the same link section name regardless of the chip type, so really, are you sure it breaks for you (a) only with the c6 (b) only when you use the macro?

[ivmarkov]

What I would also suggest is - as a test - to try using esptool.py instead of espflash for converting the ELF to BIN so as to confirm/deny that the problem is actually in espflash. As I'm still struggling to understand why it does not work with the c6 given that everything around esp_app_desc_t seems to be chip-neutral.

An easy way to install and use esptool.py might be my own esptools. Just cargo install esptools and then you have the esptool thing, and a few others in your path, ready to use (I hope).

[smithwinston]

Thank you for the explanation of the warnings for esp_app_desc!(), I'll ignore it for now!

I used esptool.py to extract the .bin with esptool.py --chip esp32c6 elf2image --output /tmp/myapp-esp32.bin --flash_size 4MB target/riscv32imac-esp-espidf/debug/myapp-esp32 and a quick hexdump doesn't show the esp_app_desc_t at offset 32, but it does look a little different to the output of espflash save-image ...:

00000000  e9 06 00 20 6a 14 80 40  ee 00 00 00 0d 00 00 00  |... j..@........|
00000010  00 ff ff 00 00 00 00 01  00 00 80 40 f8 7f 01 00  |...........@....|
00000020  6f 00 20 10 6f 00 80 1d  6f 00 40 1d 6f 00 00 1d  |o. [email protected]...|
00000030  6f 00 c0 1c 6f 00 80 1c  6f 00 40 1c 6f 00 00 1c  |[email protected]...|
00000040  6f 00 c0 1b 6f 00 80 1b  6f 00 40 1b 6f 00 00 1b  |[email protected]...|
00000050  6f 00 c0 1a 6f 00 80 1a  6f 00 40 1a 6f 00 00 1a  |[email protected]...|
00000060  6f 00 c0 19 6f 00 80 19  6f 00 40 19 6f 00 00 19  |[email protected]...|
00000070  6f 00 c0 18 6f 00 80 18  6f 00 40 18 6f 00 00 18  |[email protected]...|
00000080  6f 00 20 0a 6f 00 e0 09  6f 00 40 17 6f 00 60 09  |o. [email protected].`.|
00000090  6f 00 c0 16 6f 00 80 16  6f 00 40 16 6f 00 00 16  |[email protected]...|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The above is esptool.py elf2image vs. the following for esp flash save-image:

00000000  e9 05 02 20 6a 14 80 40  ee 00 00 00 0d 00 00 00  |... j..@........|
00000010  00 63 00 00 00 00 00 01  20 00 00 42 c8 34 13 00  |.c...... ..B.4..|
00000020  13 05 80 08 a1 45 17 03  00 00 67 00 23 0b 13 95  |.....E....g.#...|
00000030  65 00 a1 45 17 03 00 00  67 00 43 0a 13 05 00 04  |e..E....g.C.....|
00000040  91 45 17 03 00 00 67 00  63 09 31 45 91 45 17 03  |.E....g.c.1E.E..|
00000050  00 00 67 00 a3 08 13 05  00 0d 91 45 17 03 00 00  |..g........E....|
00000060  67 00 c3 07 13 05 00 07  a1 45 17 03 00 00 67 00  |g........E....g.|
00000070  e3 06 13 05 80 03 a1 45  17 03 00 00 67 00 03 06  |.......E....g...|
00000080  61 45 91 45 17 03 00 00  67 00 43 05 21 45 91 45  |aE.E....g.C.!E.E|
00000090  17 03 00 00 67 00 83 04  13 05 00 03 91 45 17 03  |....g........E..|
000000a0  00 00 67 00 a3 03 13 05  00 10 93 05 00 04 17 03  |..g.............|
000000b0  00 00 67 00 a3 02 05 65  13 05 05 84 93 05 00 04  |..g....e........|
000000c0  17 03 00 00 67 00 83 01  13 05 00 08 93 05 00 04  |....g...........|
000000d0  17 03 00 00 67 00 83 00  41 11 06 c6 22 c4 26 c2  |....g...A...".&.|
000000e0  ae 84 2a 84 97 40 08 00  e7 80 a0 69 01 c9 26 85  |..*[email protected]..&.|
000000f0  a2 85 b2 40 22 44 92 44  41 01 82 80 37 85 13 42  |...@"D.DA...7..B|

---

FWIW, a quick attempt to cargo install esptools failed with Unsupported target: os=macos, arch=aarch64, env= (see the output below), but I haven't had chance to look any further into it.

error: failed to run custom build command for `esptools v0.1.0`

Caused by:
  process didn't exit successfully: `/var/folders/5f/t_ynkwdj4f7_b4spxmxfm0nw0000gn/T/cargo-installkueHdF/release/build/esptools-877a27514611926e/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /Users/smithwinston/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esptools-0.1.0/build.rs:65:9:
  Unsupported target: os=macos, arch=aarch64, env=
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: failed to compile `esptools v0.1.0`, intermediate artifacts can be found at `/var/folders/5f/t_ynkwdj4f7_b4spxmxfm0nw0000gn/T/cargo-installkueHdF`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.