E (77) esp_image: Segment 0 load address 0x42058020, doesn't match data 0x00010020

[hugogithub9]

Bug description

I'm facing an issue that I really can't figure out or solve with my ESP32-C6 board.

Currently, I'm using a GY-BNO055 sensor connected to the board to retrieve acceleration, magnetometer, and gyroscope data. The I2C communication and data reading code works perfectly until I try to print the values.

More precisely:
When I print the converted value of just one data type (for example, acceleration), it works fine. Here's the console output in that case:

I (23) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
I (24) boot: compile time Apr 29 2025 15:14:17
I (24) boot: chip revision: v0.1
I (25) boot: efuse block revision: v0.2
I (28) boot.esp32c6: SPI Speed : 80MHz
I (32) boot.esp32c6: SPI Mode : DIO
I (36) boot.esp32c6: SPI Flash Size : 4MB
I (40) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label Usage Type ST Offset Length
I (53) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (60) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (66) boot: 2 factory factory app 00 00 00010000 003f0000
I (73) boot: End of partition table
I (76) esp_image: segment 0: paddr=00010020 vaddr=42050020 size=2b1e8h (176616) map
I (116) esp_image: segment 1: paddr=0003b210 vaddr=40800000 size=04e08h ( 19976) load
I (121) esp_image: segment 2: paddr=00040020 vaddr=42000020 size=4ffcch (327628) map
I (182) esp_image: segment 3: paddr=0008fff4 vaddr=40804e08 size=05854h ( 22612) load
I (188) esp_image: segment 4: paddr=00095850 vaddr=4080a660 size=01c2ch ( 7212) load
I (192) boot: Loaded app from partition at offset 0x10000
I (193) boot: Disabling RNG early entropy source...

However, as soon as I try to print a second value (for example, both acceleration and magnetometer), the error occurs immediately and I get this instead:

I (24) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
I (24) boot: compile time Apr 29 2025 15:14:17
I (25) boot: chip revision: v0.1
I (25) boot: efuse block revision: v0.2
I (29) boot.esp32c6: SPI Speed : 80MHz
I (33) boot.esp32c6: SPI Mode : DIO
I (37) boot.esp32c6: SPI Flash Size : 4MB
I (40) boot: Enabling RNG early entropy source...
I (45) boot: Partition Table:
I (47) boot: ## Label Usage Type ST Offset Length
I (54) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (60) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (67) boot: 2 factory factory app 00 00 00010000 003f0000
I (73) boot: End of partition table
E (77) esp_image: Segment 0 load address 0x42058020, doesn't match data 0x00010020
E (84) boot: Factory app partition is not bootable
E (88) boot: No bootable app partitions in the partition table

You can see this behavior in lines 66 and 71 of my code (currently commented).

If anyone has an idea or has experienced something similar, I'd really appreciate any advice or suggestions.
You can check the full code here: https://github.com/hugogithub9/error_esp32c6.git
Thanks in advance!

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

To Reproduce

Clone the repo linked above and build/run on an ESP32-C6 board connected to GY-BNO055 sensor.
The issue occurs when trying to print two types of converted sensor data.

Expected behavior

Printing multiple sensor data values should work without causing a crash or bootloader error.

[dickermoshe]

I'm experiencing this with the default generated template on an esp32c6 on windows

[eteq]

Same here (on an esp32c6), with the added detail that if I use the blinky example it does not happen, while the adc_oneshot example it does.

[Vollbrecht]

If you guys run newer versions of espflash than you get a default bootloader of esp-idf v5.4+. Instead of the default bootloader flashed by espflash you can bring in the one that is build alongside the project. In the same folder as your elf file there exist a bootloader.bin that can be flashed via a espflash --bootloader flag.

A alternative is to not use espflash v4 as it uses a older version of the bootloader. Or you can use cargo-espflash instead as it is automatically picking up the bootloader build in your build directory.

In the next release of the esp-idf-hal we also support newer esp-idf versions that should better run on the now default v5.4 bootloader.

At least i think that is the problems you guys see here. At least for @hugogithub9 it looks like that they are using esp-idf v5.2.3.

As a closing remark in the past it was no problem to run a older app on a newer bootloader, but upstream esp-idf made some changes plus the decision to use the bootloader in espflash this is at least for this one point in time not the case.

[dickermoshe]

In the next release of the esp-idf-hal we also support newer esp-idf versions that should better run on the now default v5.4 bootloader.

At the risk of sounding like an entitled open source user, do you have any estimate of the next release date?

(Thank you so much for maintaining this package!)

[eteq]

To add further to your helpful answer, @Vollbrecht , inspired by your comment I tried putting

ESP_IDF_VERSION = "v5.4.1"

in my .cargo/config.toml instead of the 5.3.x that I got from the template and... low and behold everything works! (at least, the adc and gpio does) So that's a viable workaround although I presume there be dragons if I'm not careful about whatever might not be compatible yet in esp-idf-hal...

[eteq]

Oh and I can confirm also that if I use the default 5.3.3 and do

espflash flash --bootloader target/riscv32imac-esp-espidf/release/bootloader.bin target/riscv32imac-esp-espidf/release/<bin-name-of-project>

(for an esp32c6) everything works as expected, thanks @Vollbrecht!

I am could make a PR to add this to some documentation but I admit I am struggling to know which is the best place to document this. espflash might make sense, although since espflash does not have to be used with esp-idf-* that might not be the right place. Maybe in the template readme? Or Perhaps it belongs in the Rust on ESP book somewhere? I'm happy to do this if I just get a hint where the most appropriate place is...

[dickermoshe]

@Vollbrecht Thank you for taking a look at this!
@eteq What an absolute life saver, thank you!

I think it would be best to modify the template to use cargo-espflash and remove the espflash recommendation.
I understand the decision to bundle the bootloader with the flashing tool makes sense for C, but for rust, which is always slightly behind, I think it would be best to use the most compatible bootloader.