Can't properly run on esp32p4 (Instruction access fault)

[kirillolenev-dm]

Root Cause Analysis & Solution

The problem - usually manifesting itself with an "Instruction access fault" panic - either when booting the bootloader, or when booting the app is caused by trying to flash on an OLD esp32p4 chip whose revision is < v3.0.

Chips with revision < v3.0 (usually 0.x or 1.x) are "preliminary" and not "production ready". Still, some board manufacturers DID release boards with those preliminary chips (both of my boards are with these old chip revisions!).

Support for these older chip revisions is trickier in both

• ESP-IDF-based projects
• espflash

(Not sure what is the status quo for esp-hal baremetal-based projects; I mean they will have the same bootloader and espflash issue, but not sure if the app image generated when building with esp-hal would even work on these older chips)

Fixes to apply in your sdkconfig.defaults

Put these two:

CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y
CONFIG_ESP32P4_REV_MIN_100=y

These instruct ESP-IDF (bootloader and I think the ESP-IDF in the app image) to generate code compatible with chip revision >= v1.0 (as opposed to v3.0, which is the default for ESP-IDF 5.5.x).

I believe, these are necessary only if you use ESP-IDF >= 5.5.X, but if you are on V5.4.X or 5.3.X, they won't do any harm, so better have those just in case anyway, regardless of the ESP-IDF version.

espflash

Use the latest version from GIT with cargo install --locked --force --git https://github.com/esp-rs/espflash espflash

(
The release on crates.io (espflash V4.3) is broken in two ways:

• Its stub is not compatible with esp32p4 revision < v3.0 so you need to pass --no-stub to it
• (And this is a roadblock for using that version) Something seems broken in it when flashing the app image, which results in "Instruction access fault"

)

EDIT: Below no longer necessary, as latest espflash in GIT fixed the bootloader issue.

Unfortunately, latest GIT espflash will also auto-flash a bootloader which is incompatible with chip revision < v3.0. I think this new bootloader was brought as part of this commit: esp-rs/espflash@15ecc03

So to fix that problem, you need to flash not just your app, but also a custom bootloader compiled for chip revision 1.x.

Fortunately, ESP-IDF-based Rust projects auto-build a bootloader.bin image as a side effect of building your app image.

The bootloader image is located at target/riscv32imafc-esp-espidf/{debug|release}/bootloader.bin.

Before rushing to flash it though, do the sdkconfig.defaults adjustments from above, then cargo clean then cargo build, or else the bootloader image (and likely the app image) will be for chip revision v3.0 still.

To flash both the app image and the bootloader, use something like this:

espflash flash --bootloader ./target/riscv32imafc-esp-espidf/{debug|release}/bootloader.bin ./target/riscv32imafc-esp-espidf/{debug|release}/your-app-image-elf --monitor

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

Bug description

A simple HelloWorld panics during startup when targeting esp32p4 with ESP_IDF 5.3.x+/ 5.4.x+ versions.
(ESP32-P4-Function-EV-Board)

ESP-ROM:esp32p4-eco2-20240710
Build:Jul 10 2024
rst:0xc (SW_CPU_RESET),boot:0x30f (SPI_FAST_FLASH_BOOT)
Core0 Saved PC:0x4ff00c9a
0x4ff00c9a - esp_restart_noos
    at /Users/kirill/Desktop/tempp4/kiolp4/.embuild/espressif/esp-idf/v5.4.1/components/esp_system/port/soc/esp32p4/system_internal.c:197
Core1 Saved PC:0x4fc012cc
SPI mode:DIO, clock div:2
load:0x4ff33ce0,len:0x162c
load:0x4ff2abd0,len:0xd6c
load:0x4ff2cbd0,len:0x3308
entry 0x4ff2abda
I (33) boot: ESP-IDF v5.4.1 2nd stage bootloader
I (33) boot: compile time Apr 16 2025 21:55:19
I (33) boot: Multicore bootloader
I (34) boot: chip revision: v1.0
I (36) boot: efuse block revision: v0.3
I (40) boot.esp32p4: SPI Speed      : 40MHz
I (44) boot.esp32p4: SPI Mode       : DIO
I (47) boot.esp32p4: SPI Flash Size : 16MB
I (51) boot: Enabling RNG early entropy source...
I (56) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (71) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (78) boot:  2 factory          factory app      00 00 00010000 00100000
I (85) boot: End of partition table
I (87) esp_image: segment 0: paddr=00010020 vaddr=40020020 size=09a40h ( 39488) map
I (104) esp_image: segment 1: paddr=00019a68 vaddr=30100000 size=00044h (    68) load
I (105) esp_image: segment 2: paddr=00019ab4 vaddr=4ff00000 size=06564h ( 25956) load
I (117) esp_image: segment 3: paddr=00020020 vaddr=40000020 size=16394h ( 91028) map
I (137) esp_image: segment 4: paddr=000363bc vaddr=4ff06564 size=05ce0h ( 23776) load
I (144) esp_image: segment 5: paddr=0003c0a4 vaddr=4ff0c280 size=01c00h (  7168) load
I (149) boot: Loaded app from partition at offset 0x10000
I (150) boot: Disabling RNG early entropy source...
I (162) cpu_start: Multicore app
Guru Meditation Error: Core  0 panic'ed (Instruction access fault). Exception was unhandled.

Core  0 register dump:
MEPC    : 0x00008082  RA      : 0x4000159e  SP      : 0x4ff3cb90  GP      : 0x4ff0ca80  
0x4000159e - do_global_ctors
    at /Users/kirill/Desktop/tempp4/kiolp4/.embuild/espressif/esp-idf/v5.4.1/components/esp_system/startup.c:102
0x4ff0ca80 - s_retention
    at ??:??
TP      : 0x00000000  T0      : 0x4fc00d56  T1      : 0x4ff0103c  T2      : 0x00000012  
0x4ff0103c - heap_caps_aligned_alloc_base
    at /Users/kirill/Desktop/tempp4/kiolp4/.embuild/espressif/esp-idf/v5.4.1/components/heap/heap_caps_base.c:108
S0/FP   : 0x40029a70  S1      : 0x4002a000  A0      : 0x00000000  A1      : 0x00000080  
A2      : 0x00000029  A3      : 0x0000001f  A4      : 0x00000001  A5      : 0x00008082  
A6      : 0xe0f1f000  A7      : 0x0000001c  S2      : 0x40020020  S3      : 0x00020020  
S4      : 0x4ff003e8  S5      : 0x00016394  S6      : 0x00010000  S7      : 0x00009a40  
0x4ff003e8 - rv_utils_dbgr_is_attached
    at /Users/kirill/Desktop/tempp4/kiolp4/.embuild/espressif/esp-idf/v5.4.1/components/riscv/include/riscv/rv_utils.h:325
S8      : 0x00010020  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000  
T3      : 0x00000000  T4      : 0x08000000  T5      : 0x04000000  T6      : 0x0c000000  
MSTATUS : 0x00001880  MTVEC   : 0x4ff00003  MCAUSE  : 0x00000001  MTVAL   : 0x00008082  
0x4ff00003 - _vector_table
    at ??:??
MHARTID : 0x00000000  

config.toml

[build]
target = "riscv32imafc-esp-espidf"

[target.riscv32imafc-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor"
rustflags = [ "--cfg",  "espidf_time64"]

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32p4"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.4"
#ESP_IDF_VERSION = "v5.3"

cargo.toml

[package]
name = "kiolp4"
version = "0.1.0"
authors = ["kirillolenev-dm <kirill@drivemode.com>"]
edition = "2021"
resolver = "2"
rust-version = "1.77"

[[bin]]
name = "kiolp4"
harness = false # do not use the built in cargo test harness -> resolve rust-analyzer errors

[profile.release]
opt-level = "s"

[profile.dev]
debug = true    # Symbols are nice and they don't increase the size on Flash
opt-level = "z"

[features]
default = ["std", "esp-idf-sys/native"]

std = ["esp-idf-sys/std"]

[dependencies]
esp-idf-sys = { version = "0.36.1", default-features = false }

[build-dependencies]
embuild = "0.33"

fn main() {
    esp_idf_sys::link_patches();
    println!("Hello, world!1");
}

To Reproduce

1. Build
2. Flash

Expected behavior

Run normally

Environment

• Crate (esp-idf-sys) version: [e.g. 0.36.1
• ESP-IDF branch or tag: 5.3.x+/ 5.4.x+
• Target device (MCU): [e.g. esp32p4]
• OS: [macOs]

[Hellymaw]

I had a similar thing happen, following the advice here I could get the application running

esptools tool --chip esp32p4 elf2image --output <out_location> --flash_size <size> target/riscv32imafc-esp-espidf/debug/<project_name>
espflash write-bin --chip esp32p4 0x10000 <out_location>

[SakiiCode]

This still happens in the recent release

[ivmarkov]

This still happens in the recent release

You seem to assume that the issue is in the esp-idf-* crates, which is very unlikely.

[ivmarkov]

I've updated the description of the issue with a root-cause analysis.

I believe this is NOT a bug in the esp-idf-* crates, but more like (a) missing support for "preliminary" esp32p4 chips in espflash (partially addressed in the meantime), as well as (b) the need to do explicit conf for these chips in ESP-IDF 5.5.X.

Will pin it so that it is visible though.