esp32c6: `esp_app_desc_t` not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

smithwinston · 2025-01-22T21:07:12Z

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

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
Run cargo add esp-idf-sys
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)

The text was updated successfully, but these errors were encountered:

smithwinston · 2025-01-23T02:47:35Z

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 · 2025-01-23T14:10:16Z

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 · 2025-01-23T14:37:49Z

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 · 2025-01-24T00:13:26Z

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 espflash 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.

ivmarkov · 2025-01-28T17:59:09Z

@smithwinston Sorry for the delay. Will try to look at both issues (esptools not working on M1 and the panic) till EOW.

ivmarkov · 2025-01-30T10:40:14Z

@smithwinston Still not at the root cause of the problem, but what I have confirmed so far, is that the esp_app_desc_t is indeed at the wrong place of the generated .bin file (for the c6 only - it seems). This by the way:
a) Happens with both esptool.py and espflash
b) Happens regardless whether you use the esp_app_desc! macro or not
c) Might be related to the ESP-IDF version in use (i.e. still to check if it happens with ESP-IDF < 5.3)

The reason for this is that the order of the segments' file in the resulting .bin is wrong (the .bin does have an internal structure consisting of segments). And this is happening with both esptool and espflash:

esptools tool --chip esp32c6 image_info light-espflash --version 2

Segments information
====================
Segment   Length   Load addr   File offs  Memory types
-------  -------  ----------  ----------  ------------
      0  0x1e5b00  0x42000020  0x00000018  IROM
      1  0x024f0  0x40800000  0x001e5b20  DRAM, BYTE_ACCESSIBLE, IRAM
      2  0x7ac04  0x421e8020  0x001e8018  IROM <-- WRONG! This should be the first segment!!!
      3  0x1ef38  0x408024f0  0x00262c24  DRAM, BYTE_ACCESSIBLE, IRAM

esptools tool --chip esp32c6 image_info light-esptool --version 2

Segments information
====================
Segment   Length   Load addr   File offs  Memory types
-------  -------  ----------  ----------  ------------
      0  0x17ff8  0x40800000  0x00000018  DRAM, BYTE_ACCESSIBLE, IRAM
      1  0x7ac04  0x421e8020  0x00018018  IROM <-- WRONG! This should be the first segment!!!
      2  0x04cf8  0x40817ff8  0x00092c24  DRAM, BYTE_ACCESSIBLE, IRAM
      3  0x04738  0x4081ccf0  0x00097924  DRAM, BYTE_ACCESSIBLE, IRAM
      4  0x03fac  0x00000000  0x0009c064  PADDING
      5  0x1e5b00  0x42000020  0x000a0018  IROM

I'll keep digging as to exactly why that happens, and whether this is something specific to the ESP-IDF Rust tooling, or happens with the C ESP-IDF tooling as well (though the latter would be very strange, as that would indicate nobody is using the c6 in production yet, which I can't believe).

ivmarkov · 2025-01-30T11:51:41Z

More info. Looking at the ELF files of an esp32s3 build, and then esp32c6 build, the ELF sections have a weird ordering, if we "order" them by looking at their addresses:

S3:

ivan@m800:~/dev/esp-idf-matter$ llvm-readelf-14 --sections target/xtensa-esp32s3-espidf/debug/examples/light
There are 40 section headers, starting at offset 0x27eb2f8:

Section Headers:
  [Nr] Name              Type            Address  Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .rtc.text         NOBITS          600fe000 262000 000100 00  WA  0   0  1
  [ 2] .rtc.force_fast   PROGBITS        600fe100 261a7a 000000 00   W  0   0  1
  [ 3] .rtc_noinit       PROGBITS        50000000 261a7a 000000 00   W  0   0  1
  [ 4] .rtc.force_slow   PROGBITS        50000000 261a7a 000000 00   W  0   0  1
  [ 5] .rtc_reserved     NOBITS          600fffe8 261fe8 000018 00  WA  0   0  8
  [ 6] .iram0.vectors    PROGBITS        40374000 094000 000403 00  AX  0   0  4
  [ 7] .iram0.text       PROGBITS        40374404 094404 017edf 00  AX  0   0  4
  [ 8] .dram0.dummy      NOBITS          3fc88000 07a000 014300 00  WA  0   0  1
  [ 9] .dram0.data       PROGBITS        3fc9c300 08e300 005b7c 00  WA  0   0 16
  [10] .noinit           NOBITS          3fca1e7c 000000 000000 00  WA  0   0  1
  [11] .dram0.bss        NOBITS          3fca1e80 093e7c 00f428 00  WA  0   0  8
  [12] .flash.text       PROGBITS        42000020 0ad020 1b4a5a 00  AX  0   0  4
  [13] .flash_rodata_dummy NOBITS        3c000020 001020 1c0000 00  WA  0   0  1
  [14] .flash.appdesc    PROGBITS        3c1c0020 001020 000100 00   A  0   0 16
  [15] .flash.rodata     PROGBITS        3c1c0120 001120 077fec 00  WA  0   0 16
  [16] .flash.rodata_noload NOBITS       3c23810c 07910c 002e4f 00   A  0   0  1
  [17] .ext_ram.dummy    NOBITS          3c000020 001020 23ffe0 00  WA  0   0  1
  [18] .iram0.text_end   NOBITS          4038c2e3 0ac2e3 00001d 00  WA  0   0  1
  [19] .iram0.data       PROGBITS        4038c300 261a7a 000000 00   W  0   0  1
  [20] .iram0.bss        PROGBITS        4038c300 261a7a 000000 00   W  0   0  1
  [21] .dram0.heap_start PROGBITS        3fcb12a8 261a7a 000000 00   W  0   0  1
  [22] .debug_aranges    PROGBITS        00000000 261a80 033f40 00      0   0  8
  [23] .debug_info       PROGBITS        00000000 2959c0 df8f4c 00      0   0  1
  [24] .debug_abbrev     PROGBITS        00000000 108e90c 0c54cc 00      0   0  1
  [25] .debug_line       PROGBITS        00000000 1153dd8 4cfa01 00      0   0  1
  [26] .debug_frame      PROGBITS        00000000 16237dc 02d098 00      0   0  4
  [27] .debug_str        PROGBITS        00000000 1650874 a9a0ee 01  MS  0   0  1
  [28] .debug_loc        PROGBITS        00000000 20ea962 4475cf 00      0   0  1
  [29] .debug_ranges     PROGBITS        00000000 2531f38 10c1e8 00      0   0  8
  [30] .debug_line_str   PROGBITS        00000000 263e120 002902 01  MS  0   0  1
  [31] .debug_loclists   PROGBITS        00000000 2640a22 0141fd 00      0   0  1
  [32] .debug_rnglists   PROGBITS        00000000 2654c1f 00085d 00      0   0  1
  [33] .comment          PROGBITS        00000000 265547c 0000ce 01  MS  0   0  1
  [34] .xtensa.info      NOTE            00000000 265554a 000038 00      0   0  1
  [35] .xt.prop          PROGBITS        00000000 2655582 000510 00      0   0  1
  [36] .xt.lit           PROGBITS        00000000 2655a92 000008 00      0   0  1
  [37] .symtab           SYMTAB          00000000 2655a9c 057ce0 10     38 5611  4
  [38] .strtab           STRTAB          00000000 26ad77c 13d97e 00      0   0  1
  [39] .shstrtab         STRTAB          00000000 27eb0fa 0001fd 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  R (retain), p (processor specific)

Notice how the flash.appdesc section has the smallest loading address so - assuming esptool/espflash orders the sections by address when generating the .bin file (which is to be checked!) it will come first.

Also an s3 image converted to .bin nicely gives:

Segments information
====================
Segment   Length   Load addr   File offs  Memory types
-------  -------  ----------  ----------  ------------
      0  0x780ec  0x3c1c0020  0x00000018  DROM
      1  0x05b7c  0x3fc9c300  0x0007810c  BYTE_ACCESSIBLE, MEM_INTERNAL, DRAM
      2  0x02380  0x40374000  0x0007dc90  MEM_INTERNAL, IRAM
      3  0x1b4a5c  0x42000020  0x00080018  IROM
      4  0x15f64  0x40376380  0x00234a7c  MEM_INTERNAL, IRAM

Notice how all flash non-executable sections from the ELF are merged in a single "DROM" segment which starts first (what we want).

In contrast, the ELF dump of an esp32c6 image gives:

ivan@m800:~/dev/esp-idf-matter$ llvm-readelf-14 --sections target/riscv32imac-esp-espidf/debug/examples/light
There are 38 section headers, starting at offset 0x33b4660:

Section Headers:
  [Nr] Name              Type            Address  Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .rtc.text         PROGBITS        50000000 46bc24 000000 00   W  0   0  1
  [ 2] .rtc.force_fast   PROGBITS        50000000 46bc24 000000 00   W  0   0  1
  [ 3] .rtc_noinit       PROGBITS        50000000 46bc24 000000 00   W  0   0  1
  [ 4] .rtc.force_slow   PROGBITS        50000000 46bc24 000000 00   W  0   0  1
  [ 5] .rtc_reserved     NOBITS          50003fe8 46bfe8 000018 00  WA  0   0  8
  [ 6] .iram0.text       PROGBITS        40800000 001000 01ccee 00  AX  0   0 256
  [ 7] .iram0.text_end   NOBITS          4081ccee 01dcee 000002 00  WA  0   0  1
  [ 8] .iram0.data       NOBITS          4081ccf0 01dcee 000000 00  WA  0   0  1
  [ 9] .iram0.bss        PROGBITS        4081ccf0 46bc24 000000 00   W  0   0  1
  [10] .dram0.data       PROGBITS        4081ccf0 01dcf0 004735 00  WA  0   0 16
  [11] .noinit           NOBITS          40821425 022425 000003 00  WA  0   0  1
  [12] .dram0.bss        NOBITS          40821430 022425 010ba0 00  WA  0   0 16
  [13] .flash.text       PROGBITS        42000020 023020 1e5b00 00  AX  0   0  2
  [14] .flash_rodata_dummy NOBITS        42000020 209020 1e8000 00  WA  0   0  1
  [15] .flash.appdesc    PROGBITS        421e8020 3f1020 000100 00   A  0   0 16
  [16] .flash.rodata     PROGBITS        421e8120 3f1120 07ab04 00  WA  0   0 16
  [17] .eh_frame_hdr     PROGBITS        42262c24 46bc24 000000 00   W  0   0  1
  [18] .eh_frame         PROGBITS        42262c24 46bc24 000000 00   W  0   0  1
  [19] .flash.tdata      PROGBITS        42262c24 46bc24 000000 00   W  0   0  1
  [20] .flash.rodata_noload NOBITS       42262c24 46bc24 003207 00   A  0   0  4
  [21] .dram0.heap_start PROGBITS        40831fd0 46bc24 000000 00   W  0   0  1
  [22] .debug_aranges    PROGBITS        00000000 46bc28 038830 00      0   0  8
  [23] .debug_info       PROGBITS        00000000 4a4458 da4f93 00      0   0  1
  [24] .debug_abbrev     PROGBITS        00000000 12493eb 0bf173 00      0   0  1
  [25] .debug_line       PROGBITS        00000000 130855e 4eb2e8 00      0   0  1
  [26] .debug_frame      PROGBITS        00000000 17f3848 0a3778 00      0   0  4
  [27] .debug_str        PROGBITS        00000000 1896fc0 a8c027 01  MS  0   0  1
  [28] .debug_loc        PROGBITS        00000000 2322fe7 4e3c9e 00      0   0  1
  [29] .debug_ranges     PROGBITS        00000000 2806c85 0f3878 00      0   0  1
  [30] .debug_line_str   PROGBITS        00000000 28fa4fd 001ce2 01  MS  0   0  1
  [31] .debug_loclists   PROGBITS        00000000 28fc1df 003235 00      0   0  1
  [32] .debug_rnglists   PROGBITS        00000000 28ff414 00049a 00      0   0  1
  [33] .comment          PROGBITS        00000000 28ff8ae 0000cc 01  MS  0   0  1
  [34] .riscv.attributes RISCV_ATTRIBUTES 00000000 28ff97a 000057 00      0   0  1
  [35] .symtab           SYMTAB          00000000 28ff9d4 96c450 10     36 600417  4
  [36] .strtab           STRTAB          00000000 326be24 14864f 00      0   0  1
  [37] .shstrtab         STRTAB          00000000 33b4473 0001eb 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  R (retain), p (processor specific)

Notice how the .flash.appdesc stuff is at address 421e8020 which is after .flash.text at 42000020.

... and the .bin file generated for this ELF is totally broken too:

Segments information
====================
Segment   Length   Load addr   File offs  Memory types
-------  -------  ----------  ----------  ------------
      0  0x17ff8  0x40800000  0x00000018  DRAM, BYTE_ACCESSIBLE, IRAM
      1  0x7ac04  0x421e8020  0x00018018  IROM <-- THIS SHOULD BE FIRST
      2  0x04cf8  0x40817ff8  0x00092c24  DRAM, BYTE_ACCESSIBLE, IRAM
      3  0x04738  0x4081ccf0  0x00097924  DRAM, BYTE_ACCESSIBLE, IRAM
      4  0x03fac  0x00000000  0x0009c064  PADDING
      5  0x1e5b00  0x42000020  0x000a0018  IROM

First of all, the 0x421e8020 should be the first segment, not the second, and then - why is it marked as "IROM"?! It is DROM actually?

smithwinston · 2025-02-01T17:20:00Z

@ivmarkov Intereresting stuff, thank you for looking into it. Yes I'd be surprised if no-one is using the C6 (although I'm leaning to the S3 simply due to the large flash size on the modules I have as I need dual images for OTA updates).

ivmarkov · 2025-02-01T17:34:27Z

@ivmarkov Intereresting stuff, thank you for looking into it. Yes I'd be surprised if no-one is using the C6

I can't believe it either, but so far this seems actually the most likely outcome.

(although I'm leaning to the S3 simply due to the large flash size on the modules I have as I need dual images for OTA updates).

FYI there are c6 modules with 8 or even 16 MB flash too. Mine are with 8MB. The big difference IMO is in
a) The s3 having the PSRAM option, which no riscv chip has yet
b) The s3 having a very powerful usb support - both device and host, while the c6 has no usb support (aside from usb-jtag-serial)

ivmarkov · 2025-02-03T18:41:02Z

@smithwinston @untbu @oddlama

I'm closing this because the bug is actually in espflash and (to some extent) in esptool.

If you revert to flashing with esptool (which is admittedly a tad more complex to install & use but not that much if you use cargo install esptools), there is a workaround:
- Pass --flash-mmu-page-size 32KB to the esptool elf2image command

For espflash flash, there is no workaround yet.

smithwinston added the bug Something isn't working label Jan 22, 2025

jessebraham added this to esp-rs Jan 22, 2025

github-project-automation bot moved this to Todo in esp-rs Jan 22, 2025

ivmarkov mentioned this issue Jan 30, 2025

bt_gatt_server example fails on esp32c6 with v5.2.3 and v5.3.2 esp-rs/esp-idf-svc#556

Closed

ivmarkov mentioned this issue Jan 30, 2025

[c6 and likely c5 and c61 specific] esptool elf2image generates wrongly-positioned esp_app_desc_t (ESPTOOL-1004) espressif/esptool#1062

Closed

ivmarkov mentioned this issue Feb 3, 2025

[esp32c6] espflash write-bin converts the ELF image to a .bin which has the DROM/IROM segment containing esp_app_desc_t at a wrong position esp-rs/espflash#741

Open

ivmarkov closed this as completed Feb 3, 2025

github-project-automation bot moved this from Todo to Done in esp-rs Feb 3, 2025

ivmarkov changed the title ~~esp_app_desc!() causing: warning: unexpected cfg condition name: esp_idf_app_compile_time_date etc.~~ esp32c6: esp_app_desc_t not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) Feb 3, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

esp32c6: `esp_app_desc_t` not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

esp32c6: `esp_app_desc_t` not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

smithwinston commented Jan 22, 2025

smithwinston commented Jan 23, 2025 •

edited

Loading

ivmarkov commented Jan 23, 2025

Bug description

ivmarkov commented Jan 23, 2025

smithwinston commented Jan 24, 2025 •

edited

Loading

ivmarkov commented Jan 28, 2025

ivmarkov commented Jan 30, 2025

ivmarkov commented Jan 30, 2025 •

edited

Loading

smithwinston commented Feb 1, 2025

ivmarkov commented Feb 1, 2025

ivmarkov commented Feb 3, 2025

esp32c6: esp_app_desc_t not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

esp32c6: esp_app_desc_t not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

Comments

smithwinston commented Jan 22, 2025

Bug description

To Reproduce

Expected behavior

Environment

smithwinston commented Jan 23, 2025 • edited Loading

ivmarkov commented Jan 23, 2025

Bug description

ivmarkov commented Jan 23, 2025

smithwinston commented Jan 24, 2025 • edited Loading

ivmarkov commented Jan 28, 2025

ivmarkov commented Jan 30, 2025

ivmarkov commented Jan 30, 2025 • edited Loading

smithwinston commented Feb 1, 2025

ivmarkov commented Feb 1, 2025

ivmarkov commented Feb 3, 2025

esp32c6: `esp_app_desc_t` not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

esp32c6: `esp_app_desc_t` not located at the beginning of the app fw image (causes OTA upgrade failures; refusal to boot with newer bootloaders) #365

smithwinston commented Jan 23, 2025 •

edited

Loading

smithwinston commented Jan 24, 2025 •

edited

Loading

ivmarkov commented Jan 30, 2025 •

edited

Loading