Calling esp_wifi::initialize on core 1 disables FPU

[cgudrian]

Since I'm running interrupt-driven, bit-banged bus communication (with sub 100µs timing constraints) on core 0 I was hoping to use core 1 for networking instead. However, setting up Wifi crashes during calibration with a Cp0Disabled exception. I was able to narrow the cause down to calling the function esp_wifi::initialize: before the call I'm able to perform floating point operations, after the call floating point operations result in the said exception. Here's an example:

Exception occurred 'Cp0Disabled (Access to the floating point coprocessor is not allowed. You may want to enable the `float-save-restore` feature of the `xtensa-lx-rt` crate.)'
Context
PC=0x400d1f86       PS=0x00060d30
0x400d1f86 - esp32_no_std_test::____embassy_main_task::{{closure}}::{{closure}}::{{closure}}
    at /home/christian/RustroverProjects/esp32-no-std-test/src/main.rs:106
A0=0x800d5d01       A1=0x3ffd46c0       A2=0x00000003       A3=0x00000002       A4=0x400e3340
0x3ffd46c0 - esp32_no_std_test::____embassy_main_task::{{closure}}::STATIC_CELL
    at ??:??
0x400e3340 - esp_wifi_set_mode
    at ??:??
A5=0x00000000       A6=0x00000001       A7=0x400e34b0       A8=0x3f4082bc       A9=0x00000004
0x400e34b0 - esp_wifi_internal_reg_rxcb
    at ??:??
A10=0x400d1e60      A11=0x00001000      A12=0x3ffb0180      A13=0x3ffb0098      A14=0x3ffb0180
0x400d1e60 - core::ptr::read_volatile
    at /home/christian/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1706
0x3ffb0180 - g_wifi_event_mask
    at ??:??
0x3ffb0098 - esp_wifi::wifi::G_CONFIG
    at ??:??
0x3ffb0180 - g_wifi_event_mask
    at ??:??
A15=0x4011b31c
0x4011b31c - sha256_vector
    at /COMPONENT_WPA_SUPPLICANT_DIR/src/crypto/sha256-internal.c:27
SAR=00000018
EXCCAUSE=0x00000020 EXCVADDR=0x00000000
LBEG=0x4000c46c     LEND=0x4000c477     LCOUNT=0x00000000
THREADPTR=0x00000000
SCOMPARE1=0x00000100
BR=0x00000000
ACCLO=0x00000000    ACCHI=0x00000000
M0=0x00000000       M1=0x00000000       M2=0x00000000       M3=0x00000000
F64R_LO=0x3ffd8720  F64R_HI=0x3ffd6730  F64S=0x00060d20
0x3ffd8720 - gScanStruct
    at ??:??
0x3ffd6730 - esp_wifi::compat::timer_compat::TIMERS
    at ??:??
FCR=0x00000006      FSR=0x3ffec080
0x3ffec080 - esp_wifi::HEAP_DATA
    at ??:??
F0=0x3fff3ce4       F1=0x3ffd7220       F2=0x3f4044bc       F3=0x0000001e       F4=0x00000000
0x3fff3ce4 - esp_wifi::HEAP_DATA
    at ??:??
0x3ffd7220 - tls_ref_count
    at ??:??
F5=0x00060d20       F6=0x800d1e1b       F7=0x3ffd46a0       F8=0x00000001       F9=0x400e0328
0x3ffd46a0 - esp32_no_std_test::____embassy_main_task::{{closure}}::STATIC_CELL
    at ??:??
0x400e0328 - esp_wifi::wifi::recv_cb_ap
    at ??:??
F10=0x3ffd9da0      F11=0x3ffe9c20      F12=0x00000000      F13=0x00000068      F14=0x800d5d01
0x3ffd9da0 - g_osi_funcs_p
    at ??:??
0x3ffe9c20 - esp_wifi::HEAP_DATA
    at ??:??
F15=0x3ffd46c0
0x3ffd46c0 - esp32_no_std_test::____embassy_main_task::{{closure}}::STATIC_CELL
    at ??:??
0x400d5d62
core::fmt::Arguments::new_v1
    at /home/christian/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:354

with line 106 in main.rs looking like this:

let dummy = (1000f32 / dummy) as u32;

Setting the mentioned feature of the xtensa-lx-rt crate had no effect.

The core 1 context has a stack size of 32k. The global allocator has 112k to give. Core 0 is basically idling around waiting for GPIO activity.

I would like to understand what's going on here and how to fix it (if possible).

Christian

[bugadani]

Can you please share an example I can try? I have a suspect issue, but all my efforts in creating a test case have failed so far.

[bugadani]

Hopefully #2315 finally resolves all these issues. But to be fair, if you have really enabled float-save-restore this issue shouldn't have been possible to happen.

[cgudrian]

I haven't yet had the time to prepare a minimal example. I'll have a look at the issue and the float-save-restore feature this evening. Thanks for looking into this!

[cgudrian]

I can confirm, that the float-save-restore feature does not fix the issue. I will try to backport your fix to v0.20.1, as updating to main broke too much.

[bugadani]

I would also like to ask you to add #2322 to the list of changes you try out.

[cgudrian]

After all I've switched to the main branch now. While the crash performing a simple floating point division is gone, Wifi initialization crashes with a Cp0Disabled exception in the function get_rf_freq_init:

Exception occurred 'Cp0Disabled (Access to the floating point coprocessor is not allowed. You may want to enable the `float-save-restore` feature of the `xtensa-lx-rt` crate.)'
Context
PC=0x4010acc2       PS=0x00060f15
0x4010acc2 - ram_rfpll_set_freq
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:427
A0=0x8010af63       A1=0x3ffb4680       A2=0x00258000       A3=0x000000ff       A4=0x00000000
0x3ffb4680 - esp32_no_std_test::____embassy_main_task::{{closure}}::HEAP
    at ??:??
A5=0x3ffb46cc       A6=0x02000000       A7=0x80060f05       A8=0x8010acc2       A9=0x3ffb4660
0x3ffb46cc - esp32_no_std_test::____embassy_main_task::{{closure}}::HEAP
    at ??:??
0x3ffb4660 - esp32_no_std_test::____embassy_main_task::{{closure}}::HEAP
    at ??:??
A10=0x4a480000      A11=0x41490000      A12=0x00000000      A13=0x40080000      A14=0x02000000
0x40080000 - _WindowOverflow4
    at /home/christian/RustroverProjects/esp32-no-std-test/esp-hal/xtensa-lx-rt/src/exception/context.rs:309
A15=0x80060f05
SAR=0000001d
EXCCAUSE=0x00000020 EXCVADDR=0x00000000
LBEG=0x400894ac     LEND=0x400894d9     LCOUNT=0x00000000
0x400894ac - i2c_write_master
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:127
0x400894d9 - i2c_write_master
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:127
THREADPTR=0x00000000
SCOMPARE1=0x00000100
BR=0x00000000
ACCLO=0x00000000    ACCHI=0x00000000
M0=0x00000000       M1=0x00000000       M2=0x00000000       M3=0x00000000
F64R_LO=0x00000000  F64R_HI=0x00000000  F64S=0x00000000
FCR=0x00000000      FSR=0x00000000
F0=0x00000000       F1=0x0012c000       F2=0x000fffff       F3=0x00000000       F4=0x00000000
F5=0x00000000       F6=0x00180000       F7=0x7ff00000       F8=0xffffffff       F9=0x00000000
F10=0x00000008      F11=0x00000000      F12=0x00000000      F13=0x00000000      F14=0x00000000
F15=0x00000000
0x4010b306
get_rf_freq_init
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:1316
0x4010bfff
get_rf_freq_init
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:1291
0x4010c118
rf_init
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_ana.c:1135
0x4010f2bb
register_chipv7_phy
    at /home/lxf/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7.c:3987
0x400e02ac
esp_wifi::common_adapter::chip_specific::phy_enable::{{closure}}
    at /home/christian/RustroverProjects/esp32-no-std-test/esp-hal/esp-wifi/src/common_adapter/common_adapter_esp32.rs:68
0x400f44f1
wifi_hw_start
    at ??:??
0x400f4d3d
wifi_start_process
    at ??:??
0x400f30c1
ieee80211_ioctl_process
    at ??:??
0x40083420
ppTask
    at ??:??

[cgudrian]

Adding

xtensa-lx-rt = { path = "esp-hal/xtensa-lx-rt", features = ["esp32", "float-save-restore"]}

to Cargo.toml did the trick.