"No bootable app partitions in the partition table" unless using release profile.

[BenMagill]

Bug description

When running the template program with cargo run, it successfully flashes but then fails to run on the esp32c6 with the below messsage.

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x3 (LP_SW_HPSYS),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4001974a
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x16b8
load:0x4086c110,len:0xe90
load:0x4086e610,len:0x3054
entry 0x4086c11a
I (22) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
I (23) boot: compile time Apr 29 2025 15:14:17
I (23) boot: chip revision: v0.1
I (24) boot: efuse block revision: v0.3
I (27) boot.esp32c6: SPI Speed      : 80MHz
I (31) boot.esp32c6: SPI Mode       : DIO
I (35) boot.esp32c6: SPI Flash Size : 4MB
I (39) boot: Enabling RNG early entropy source...
I (43) boot: Partition Table:
I (46) boot: ## Label            Usage          Type ST Offset   Length
I (52) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (59) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (65) boot:  2 factory          factory app      00 00 00010000 003f0000
I (72) boot: End of partition table
E (75) esp_image: Segment 0 load address 0x42058020, doesn't match data 0x00010020
E (82) boot: Factory app partition is not bootable
E (87) boot: No bootable app partitions in the partition table

However, when using cargo run --release the program runs successfully.

Changing the dev profile opt-level to "s" (the same as release) does not work either.

• Would you like to work on a fix? y

To Reproduce

1. cargo generate esp-rs/esp-idf-template cargo
2. cd <program dir>
3. cargo run

Expected behavior

Example program runs without fail.

Environment

• ESP-IDF branch or tag: v5.3.3
• Target device (MCU): esp32c6
• OS: Arch Linux
• How did you install the environment: Unsure what this means
• espflash: 4.0.1

[BenMagill]

Update: modifying [profile.dev] opt-level to the following values allows the program to run correctly.

• 0
• 1
• 2
• 3

I am still happy to work on a solution to the problem and investigate it further, as the "s" opt-level only working for release profile is very weird.

The release profile also works with both opt-level "z" and "s".

[ivmarkov]

I don't think the root cause is miscompilation by rustc.

Rather, it is another instance of the case where a newer bootloader (ESP IDF 5.4.2) cannot boot an app built with an older version of ESP-IDF (5.3.2).

You either need to flash a 5.3.2 bootloader.bin (you can find it in target/debug|release) as well as a part table of your choice, or you need to upgrade your project to ESP-IDF 5.4.2. for the latter, you might need to patch all your esp-idf-* crates from GIT. We are working on a new release, but we are not there yet.

[BenMagill]

Thanks! I just noticed the esp-idf version in the boot logs is different to that configured in .cargo/conifg.toml, so what you said makes sense.

Are there any risks in flashing an older bootloader version to the MCU?

Also, is there any way I could help towards the new release?

[ivmarkov]

Are there any risks in flashing an older bootloader version to the MCU?

Not at all. Espressif MCUs are unbrickable as long as you don't use EFUSE, and you don't.

Also, is there any way I could help towards the new release?

Not sure. We are kind of there almost.

[ivmarkov]

Actually you can help.

Patch all your esp-idf-* crates from GIT as per my previous comment.
And then check that the resulting app image (it will use ESP-IDF V5.4.2 by default) flashes and runs fine on your hardware.

[atc0m]

I can confirm that modifying the ESP_IDF_VERSION to v5.4.1 worked, the device was flashed and I can see "Hello, world!"