ESP32-C3 `esp_wifi::init` fails with `Store/AMO access fault`

jakoblell commented 1 week ago

Bug description

After updating dependencies in a project (was quite a rabbit hole due to all the breaking API changes from the past couple of months) the WiFi initalization (function esp_wifi::init) fails with the error Store/AMO access fault, here is the full error log:

INFO - esp_hal::init done

Exception 'Store/AMO access fault' mepc=0x420036f6, mtval=0x00000000
0x420036f6 - esp_wifi::preempt::allocate_main_task
    at ??:??
TrapFrame
PC=0x420036f6         RA/x1=0x420036f4      SP/x2=0x3fc87f80      GP/x3=0x3fcce280      TP/x4=0x00000000
0x420036f6 - esp_wifi::preempt::allocate_main_task
    at ??:??
0x420036f4 - esp_wifi::preempt::allocate_main_task
    at ??:??
0x3fc87f80 - __global_pointer$
    at ??:??
T0/x5=0x00000027      T1/x6=0x42005c5c      T2/x7=0x0000000b      S0/FP/x8=0x3fcce2b0   S1/x9=0x0000009c
0x42005c5c - esp_hal::rtc_cntl::rtc::init
    at ??:??
A0/x10=0x00000000     A1/x11=0x80000000     A2/x12=0x00000000     A3/x13=0x00000001     A4/x14=0x00000000
A5/x15=0xffffdfff     A6/x16=0x3c0505bc     A7/x17=0x0000000f     S2/x18=0x00000001     S3/x19=0x00000000
0x3c0505bc - .Lanon.fad58de7366495db4650cfefac2fcd61.54
    at ??:??
S4/x20=0x3fc89000     S5/x21=0x00000000     S6/x22=0x00000000     S7/x23=0x00000000     S8/x24=0x00000000
0x3fc89000 - embassy_executor::_export::ARENA
    at ??:??
S9/x25=0x00000000     S10/x26=0x00000000    S11/x27=0x00000000    T3/x28=0x3c0505bc     T4/x29=0x0000000f
0x3c0505bc - .Lanon.fad58de7366495db4650cfefac2fcd61.54
    at ??:??
T5/x30=0x00000000     T6/x31=0x00000000

MSTATUS=0x00001801
MCAUSE=0x00000007
MTVAL=0x00000000

0x42003ff8
0x42003ff8 - esp_wifi::tasks::init_tasks
    at ??:??
0x42000842
0x42000842 - esp_wifi::init
    at ??:??
0x4200035c
0x4200035c - embassy_executor::raw::TaskStorage<F>::poll
    at ??:??
0x42004bb8
0x42004bb8 - embassy_executor::raw::Executor::poll
    at ??:??
0x4200020a
0x4200020a - esp_hal_embassy::executor::thread::Executor::run
    at ??:??
0x420008c0
0x420008c0 - main
    at ??:??
0x4200587c
0x4200587c - hal_main
    at ??:??
0x42000132
0x42000132 - _start_rust
    at ??:??

To Reproduce

I've created a minimal test case to reproduce the issue:

Cargo.toml:

[package]
name = "minimal_testcase"
version = "0.1.0"
edition = "2021"

[dependencies]
embassy-executor    = { version = "0.6.1", features = ["task-arena-size-40960"] }
embassy-futures     = "0.1.1"
embassy-usb         = { version = "0.3.0", default-features = false, optional = true }
embedded-hal        = { version = "1.0.0"}
embedded-hal-async  = "1.0.0"
embassy-time = { version = "0.3.1", features = ["generic-queue"]}
esp-backtrace = { version = "0.14.2", features = ["esp32c3", "panic-handler", "exception-handler", "println"] }
esp-hal = { version = "0.21.1", features = ["esp32c3"] }
esp-hal-embassy = { version = "0.4.0", features = ["esp32c3"] }
esp-println = { version = "0.12.0", features = ["esp32c3", "log"] }
esp-wifi = { version = "0.10.1", features = ["esp32c3", "wifi", "async", "embassy-net"] }
embassy-net = { version = "0.4.0", features = ["dhcpv4", "dhcpv4-hostname"] }
log = "0.4.22"
static_cell = { version = "2.1.0" , features = ["nightly"]}

src/main.rs:

#![no_std]
#![no_main]
use esp_backtrace as _;  // Required for panic handler via "panic-handler" feature
use esp_println::println;
use esp_hal::prelude::{main, entry, CpuClock};
use embassy_executor::Spawner;
use esp_hal::interrupt::Priority;
use esp_hal::peripherals::Peripherals;
use esp_hal::timer::timg::TimerGroup;
use esp_hal_embassy::InterruptExecutor;
use embassy_time::{Ticker, Duration, Instant, Timer};
use esp_hal::rng::Rng;
use esp_hal::timer::systimer::SystemTimer;
use esp_wifi::{EspWifiInitFor};
use esp_wifi::wifi::{ClientConfiguration, Configuration, WifiController, WifiDevice, WifiEvent, WifiStaDevice, WifiState};
use embassy_net::{Config, DhcpConfig, Stack, StackResources};
use esp_hal::Blocking;
use esp_hal::gpio::{Io, Level, Output};
use esp_hal::rmt::{Channel, Rmt};
use esp_hal::gpio::OutputPin;

use log::{info, error, trace};

use static_cell::{StaticCell, make_static};

#[main]
async fn main(_low_prio_spawner: Spawner) {
    esp_println::logger::init_logger_from_env();
    let peripherals = esp_hal::init({
        let mut config = esp_hal::Config::default();
        config.cpu_clock = CpuClock::max();
        config
    });
    info!("esp_hal::init done");
    let timg0 = TimerGroup::new(peripherals.TIMG0);
    let init = esp_wifi::init(
        EspWifiInitFor::Wifi,
        timg0.timer0,
        Rng::new(peripherals.RNG),
        peripherals.RADIO_CLK
    ).expect("esp_wifi::initialize failed");

    panic!("This will not be reached due to this bug");
    loop{
        Timer::after_secs(10).await;
    }
}

.cargo/config.toml:

[target.riscv32imc-unknown-none-elf]
runner = "espflash flash --baud 1152000 --monitor"

[build]
target = "riscv32imc-unknown-none-elf"

rustflags = [
  "-C", "link-arg=-Tlinkall.x",

  # This is required for WiFi
  "-C", "link-arg=-Trom_functions.x",

  # Required to obtain backtraces (e.g. when using the "esp-backtrace" crate.)
  # NOTE: May negatively impact performance of produced code
  "-C", "force-frame-pointers",
]

[env]
ESP_LOG = "TRACE"

Environment

Board: esp32-c3-devkit-m1 (with an ESP32-C3 WROOM module)
Dependency/package versions: See Cargo.toml above
Rust version: The issue can be reproduced with stable (rustc 1.82.0 (f6e511eec 2024-10-15)) and nightly (rustc 1.84.0-nightly (fbab78289 2024-11-04))

bjoernQ commented 1 week ago

Thanks for providing your minimal reproducer.

Seems you are missing a heap allocator like it's done here: https://github.com/esp-rs/esp-hal/blob/39c0baf2c7bf3a45cd16a844f100c52d84c9b727/examples/src/bin/wifi_embassy_dhcp.rs#L59

For more information refer to the migration guide here: https://github.com/esp-rs/esp-hal/blob/v0.21.1/esp-wifi/MIGRATING-0.9.md#memory-allocation

In the upcoming version we'll provide a better error message in this case.

Going to close this issue - feel free to re-open if my suggestions don't fix the issue

jakoblell commented 1 week ago

Thanks for the suggestion, it indeed fixes the issue.

However it might still be a good idea to add compile-time safety for this (so that the code doesn't compile if the memory allocator is missing). If that is not possible it would also help to have at least a panic message with a clear indication of what the problem is.

bjoernQ commented 1 week ago

Thanks for the suggestion, it indeed fixes the issue.

However it might still be a good idea to add compile-time safety for this (so that the code doesn't compile if the memory allocator is missing). If that is not possible it would also help to have at least a panic message with a clear indication of what the problem is.

I don't see a (good) way to get compile-time safety but in the upcoming release you will get a more helpful panic in this case

esp-rs / esp-hal