Runtime error Image requires efuse blk rev >= v0.5 only in recent versions of esp-idf-matter

[oddlama]

Some months ago I was able to run the light example project on my esp32c6 modules successfully. Today I had some time to revisit this, but unfortunately the exact same physical esp32c6 device which worked back then doesn't allow me to start the application anymore. I'm immediately stuck in a boot loop which complains that E (96) boot_comm: Image requires efuse blk rev >= v0.5, but chip is v0.3, and I have no idea what changed.

I tried this on two different modules, which both worked with this project in July 2024. Do you maybe have an idea what might be going on?

Boot log of chip 1 (XIAO Seeed esp32c6)

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x3 (LP_SW_HPSYS),boot:0x1e (SPI_FAST_FLASH_BOOT)
Saved PC:0x4001974a
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x18ec
load:0x4086c110,len:0xe5c
load:0x4086e610,len:0x2f50
entry 0x4086c11a
I (22) boot: ESP-IDF v5.3.2 2nd stage bootloader
I (23) boot: compile time Jan 26 2025 19:15:47
I (24) boot: chip revision: v0.1
I (25) boot: efuse block revision: v0.3
I (30) boot.esp32c6: SPI Speed      : 80MHz
I (35) boot.esp32c6: SPI Mode       : DIO
I (39) boot.esp32c6: SPI Flash Size : 4MB
I (44) boot: Enabling RNG early entropy source...
I (50) boot: Partition Table:
I (53) boot: ## Label            Usage          Type ST Offset   Length
I (60) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (68) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (75) boot:  2 factory          factory app      00 00 00010000 00300000
I (83) boot: End of partition table
I (87) esp_image: segment 0: paddr=00010020 vaddr=42000020 size=1e4050h (1982544) map
E (96) boot_comm: Image requires efuse blk rev >= v0.5, but chip is v0.3
E (103) boot: Factory app partition is not bootable
E (108) boot: No bootable app partitions in the partition table

Boot log of chip 2 (Bare module from mouser, bought in early 2024)

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x3 (LP_SW_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x4001974a
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x18ec
load:0x4086c110,len:0xe5c
load:0x4086e610,len:0x2f50
entry 0x4086c11a
I (24) boot: ESP-IDF v5.3.2 2nd stage bootloader
I (24) boot: compile time Jan 26 2025 19:15:47
I (25) boot: chip revision: v0.0
I (27) boot: efuse block revision: v0.1
I (31) boot.esp32c6: SPI Speed      : 80MHz
I (36) boot.esp32c6: SPI Mode       : DIO
I (41) boot.esp32c6: SPI Flash Size : 4MB
I (46) boot: Enabling RNG early entropy source...
I (51) boot: Partition Table:
I (55) boot: ## Label            Usage          Type ST Offset   Length
I (62) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (69) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (77) boot:  2 factory          factory app      00 00 00010000 00300000
I (84) boot: End of partition table
I (89) esp_image: segment 0: paddr=00010020 vaddr=42000020 size=1e4050h (1982544) map
E (97) boot_comm: Image requires efuse blk rev >= v0.5, but chip is v0.1
E (105) boot: Factory app partition is not bootable
E (110) boot: No bootable app partitions in the partition table

[Comet1903]

I faced the exact same issue with my boards (also XIAO Speed esp32c6). A quick workaround for me was instead of running

cargo espflash flash --target riscv32imac-esp-espidf --example light --features examples --monitor

to build and flash separate

# build
cargo build --target riscv32imac-esp-espidf --example light --features examples

# flash
espflash flash target/riscv32imac-esp-espidf/debug/examples/light --monitor

This is not the fix, but I also think that this repo isn't the right place for it either.

[oddlama]

Wow thank you, spot on! I have no idea why this should produce another binary, but somehow it does. :D
I agree that this is probably nothing to do with this repository then, do you have a suggestion where it would be a better fit? I cannot imagine which component might be responsible for this.

EDIT: Unfortunately the application seems to dislike the BLE version (ESP_ERR_INVALID_VERSION), so maybe the original error was just ignored by this two-step build and should actually fail too.

I (1126) BLE_INIT: Using main XTAL as clock source
INIT ERROR:Invalid version info:20231124, 20240422, 5a5aa5a5, 5a5aa5a5
W (1146) BLE_INIT: r_ble_controller_init failed 266

thread '<unnamed>' panicked at /home/user/projects/embedded/esp-idf-matter/src/wireless.rs:150:73:
called `Result::unwrap()` on an `Err` value: ESP_ERR_INVALID_VERSION (error code 266)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

abort() was called at PC 0x420cf8b9 on core 0
0x420cf8b9 - panic_abort::__rust_start_panic::abort
    at /nix/store/ry6vz80rdp0h1fc84qf40cd5swk15nbz-rust-default-1.86.0-nightly-2025-01-06/lib/rustlib/src/rust/library/panic_abort/src/lib.rs:48
Core  0 register dump:
MEPC    : 0x40801998  RA      : 0x4080bc0a  SP      : 0x4083bd40  GP      : 0x4081d504  
0x40801998 - panic_abort
[...]

[untbu]

It looks like the problem isn't the binary, but the bootloader. cargo espflash flash flashes both the binary and the bootloader. espflash flash only flashes the bootloader if you tell it to do so. As the bootloader is build by esp-idf, the right repo is probably https://github.com/espressif/esp-idf

[Comet1903]

EDIT: Unfortunately the application seems to dislike the BLE version (ESP_ERR_INVALID_VERSION), so maybe the original error was just ignored by this two-step build and should actually fail too.

The BLE version issue is still unresolved for me, since I haven’t had the time to look deeper into it yet.

@untbu and I have tried to figure it out but didn’t find a solution. Maybe you/we should open a new issue to track this?

[oddlama]

The BLE version issue is still unresolved for me, since I haven’t had the time to look deeper into it yet.

Maybe you/we should open a new issue to track this?

Yeah that would be great! It's probably better if you create the issue since you already did some research and can probably provide more context