rust-esp32-std-demo: ESP32C3: "esp_image: invalid segment length" when running a build based on ESP-IDF V4.3.X

UPDATE: WORKAROUNDS

If you are using the ESP32C3 chip, and once the binary is flashed you see this error:

E (174) esp_image: invalid segment length 0xffee

… potentially followed by these:

E (174) boot: Factory app partition is not bootable
E (174) boot: No bootable app partitions in the partition table

… then you are hitting this problem.

We are not sure yet what is causing the invalid segment size. It might be the esp-idf-sys build of ESP V4.3.X, or the ESP-IDF V4.3.X itself. However we know that:

  • It does not always happen (depends on the concrete size your program happens to have when compiled to binary)
  • Happens ONLY for ESP32C3 + ESP-IDF V4.3.X (later versions work OK).

Workaround (NOTE: only for platforms <> Windows; for Windows, currently there is no (easy) workaround):

To workaround the issue, you have to use a version > ESP-IDF 4.3.X. Using version > 4.3.X is not possible with the PIO build, hence why you also need to switch to the native build. This leaves you with two options:

  • Use ESP-IDF master. Unfortunately this one cannot be built at the moment. We have not yet looked into this issue, might be an issue in ESP-IDF itself
  • Use ESP-IDF release/v4.4 branch <-- This is what I would recommend

So to build, please use export ESP_IDF_VERSION=release/v4.4; cargo build --features native.

Unfortunately, the above will not work on Windows (i.e. on Windows currently there is simply no workaround for that problem), because the native build generates too long command lines on Windows. We are aware of that, and the fix should actually be implemented inside ESP-IDF itself (to be more precise, on how they build the ESP-IDF GCC toolchains for Windows). We are waiting for the next GCC Windows toolchains release from them.

===============================================

Original bug report: When I comment out all of the code and just print something, the ESP32C3 board I’m using prints:

E (174) esp_image: invalid segment length 0xffee
E (174) boot: Factory app partition is not bootable
E (174) boot: No bootable app partitions in the partition table

My partition table looks like:

I (62) boot: ## Label            Usage          Type ST Offset   Length
I (69) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (77) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (84) boot:  2 factory          factory app      00 00 00010000 00100000

I’ve been looking into it for a bit but it seems that the padding is not aligned to 4-byte, which is causing this error to pop up. I’m using esptool.py to generate an app image from the compiled ELF.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 35 (17 by maintainers)

Commits related to this issue

Most upvoted comments

With the above ^^^ commits I would consider this issue finally fixed!

+5
ivmarkov on Jan 11, 2022

I’m also running into this error with the default PIO build system*. However, I can’t get native building to work. The last log lines are

  Cloning into 'K:/Code/rust/esp32-std/.embuild/espressif/esp-idf-v4.3.1/components/nghttp/nghttp2/third-party/neverbleed'...
  From https://github.com/tatsuhiro-t/neverbleed
   * branch            b967ca054f48a36f82d8fcdd32e54ec5144f2751 -> FETCH_HEAD
  From https://github.com/espressif/tinyusb
   * branch              334e95fac52a607150157ae5199a19e11f843982 -> FETCH_HEAD
  WARNING: You are using pip version 20.3.1; however, version 21.3.1 is available.
  You should consider upgrading via the 'K:\Code\rust\esp32-std\.embuild\espressif\python_env\idf4.3_py3.8_env\Scripts\python.exe -m pip install --upgrade pip' command.
  error: patch failed: components/xtensa/stdatomic.c:133
  error: components/xtensa/stdatomic.c: patch does not apply
  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 1

Forget about using the native build on Windows currently. See below.

I attempted to use a local ESP-IDF v4.3.1 and that didn’t work either, but I’m not sure I used the right combination of env vars. Is there something I’m doing wrong? [Log here]

This is not (yet) supported, but is work in progress (i.e. supplying your own local copy of ESP-IDF). You can still supply your own Git clone of ESP-IDF, but then see below - that’s not necessary.

*: Without touching anything other than telling it to target C3, I can compile and it works. It’s when I start experimenting that it breaks.

Yes, the issue does not always happen.

To workaround the issue, you have to use a version > ESP-IDF 4.3.X. Using version > 4.3.X is not possible with the PIO build, hence why you also need to switch to the native build. This leaves you with two options:

  • Use ESP-IDF master. Unfortunately this one cannot be built at the moment. We have not yet looked into this issue, might be an issue in ESP-IDF itself
  • Use ESP-IDF release/v4.4 branch <-- This is what I would recommend

So to build, please use export ESP_IDF_VERSION=release/v4.4; cargo build --features native.

Unfortunately, the above will not work on Windows (i.e. on Windows currently there is simply no workaround for that problem), because the native build generates too long command lines on Windows. We are aware of that, and the fix should actually be implemented inside ESP-IDF itself (to be more precise, on how they build the ESP-IDF GCC toolchains for Windows). We are waiting for the next GCC Windows toolchains release from them.

+1
ivmarkov on Jan 10, 2022

@ivmarkov @FrozenDroid May I ask you to attach an ELF file which triggers this issue over at espressif/esptool#661? This would help the folks working on esptool pick up the issue report quicker, since they won’t have to set up rust-esp32-std-hello to reproduce. Thanks in advance!

Done! Check the esptool issue.

+1
FrozenDroid on Sep 22, 2021

@ivmarkov @FrozenDroid May I ask you to attach an ELF file which triggers this issue over at https://github.com/espressif/esptool/issues/661? This would help the folks working on esptool pick up the issue report quicker, since they won’t have to set up rust-esp32-std-hello to reproduce. Thanks in advance!

+1
igrr on Sep 21, 2021

Ha! You are completely right!

I just reproduced it. Full log just in case:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403d11a0
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x17a8
load:0x403ce000,len:0x894
load:0x403d0000,len:0x2bf8
entry 0x403ce000
I (57) boot: ESP-IDF v4.3-beta2-2-g9a2d251912 2nd stage bootloader
I (57) boot: compile time 19:26:26
I (57) boot: chip revision: 3
I (60) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (68) boot.esp32c3: SPI Speed      : 80MHz
I (72) boot.esp32c3: SPI Mode       : DIO
I (77) boot.esp32c3: SPI Flash Size : 4MB
I (82) boot: Enabling RNG early entropy source...
I (87) boot: Partition Table:
I (91) boot: ## Label            Usage          Type ST Offset   Length
I (98) boot:  0 sec_cert         unknown          3f 00 0000d000 00003000
I (105) boot:  1 nvs              WiFi data        01 02 00010000 00006000
I (113) boot:  2 otadata          OTA data         01 00 00016000 00002000
I (121) boot:  3 phy_init         RF data          01 01 00018000 00001000
I (128) boot:  4 ota_0            OTA app          00 10 00020000 00190000
I (136) boot:  5 ota_1            OTA app          00 11 001b0000 00190000
I (143) boot:  6 fctry            WiFi data        01 02 00340000 00006000
I (151) boot:  7 coredump         Unknown data     01 03 00350000 00010000
I (158) boot: End of partition table
E (163) boot: ota data partition invalid and no factory, will try all partitions
I (171) boot_comm: chip revision: 3, min. application chip revision: 0
I (178) esp_image: segment 0: paddr=00020020 vaddr=3c030020 size=11148h ( 69960) map
I (197) esp_image: segment 1: paddr=00031170 vaddr=3fc8ae00 size=01bf8h (  7160) load
I (199) esp_image: segment 2: paddr=00032d70 vaddr=40380000 size=0aca4h ( 44196) load
I (212) esp_image: segment 3: paddr=0003da1c vaddr=50000000 size=00010h (    16) load
I (212) esp_image: segment 4: paddr=0003da34 vaddr=00000000 size=025e4h (  9700) 
I (222) esp_image: segment 5: paddr=00040020 vaddr=42000020 size=2a2e4h (172772) map
E (255) esp_image: invalid segment length 0xffee
E (256) boot: OTA app partition slot 0 is not bootable
E (256) esp_image: image at 0x1b0000 has invalid magic byte
W (262) esp_image: image at 0x1b0000 has invalid SPI mode 255
W (268) esp_image: image at 0x1b0000 has invalid SPI size 15
E (274) boot: OTA app partition slot 1 is not bootable
E (280) boot: No bootable app partitions in the partition table

Segment info, just in case:

esptool.py v3.1
Image version: 1
Entry point: 403802ca
8 segments

Segment 1: len 0x11148 load 0x3c030020 file_offs 0x00000018 [DROM]
Segment 2: len 0x01bf8 load 0x3fc8ae00 file_offs 0x00011168 [DRAM,BYTE_ACCESSIBLE]
Segment 3: len 0x0aca4 load 0x40380000 file_offs 0x00012d68 [IRAM]
Segment 4: len 0x00010 load 0x50000000 file_offs 0x0001da14 [RTC_IRAM,RTC_DRAM]
Segment 5: len 0x025e4 load 0x00000000 file_offs 0x0001da2c [PADDING]
Segment 6: len 0x2a2e4 load 0x42000020 file_offs 0x00020018 [IROM]
Segment 7: len 0x0ffee load 0x00000000 file_offs 0x0004a304 [PADDING]
Segment 8: len 0x009e4 load 0x4202a302 file_offs 0x0005a2fa [IROM]
Checksum: b4 (valid)
Validation Hash: 5ced93819a4a522162f07e7a2d227dfe91df0998b8c80ad89411c73ced59a5e2 (valid)
+1
ivmarkov on Sep 16, 2021
Read more comments on GitHub
← rust-esp32-std-demo: Could not find specification for target "xtensa-esp32-espidf"
gulp-typescript: Could not find input file .../________________empty.ts. This is probably an issue of gulp-typescript. →