esp-wifi lockup on esp32c3 when using the embassy InterruptExecutor

[kaspar030]

I'm trying to add esp support to RIOT-rs, but I'm having some trouble with esp-wifi.

Basically esp-wifi gets stuck waiting for a semaphore at some point.
I suspect it's because I'm using the InterruptExecutor.

I can reproduce the issue with examples/embassy_dhcp.rs, modified to use the InterruptExecutor.
Here is a gist with the diff.

And here is the end of the trace log:

trace output

...
start connection task
Device capabilities: Ok(EnumSet(Client))
TRACE - task get current task - return 0x2
TRACE - mutex_lock ptr = 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - task get current task - return 0x2
TRACE - mutex_unlock 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - task get current task - return 0x2
TRACE - mutex_lock ptr = 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - task get current task - return 0x2
TRACE - mutex_unlock 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - task get current task - return 0x2
TRACE - mutex_lock ptr = 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - task get current task - return 0x2
TRACE - mutex_unlock 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - wifi_calloc 204 1
TRACE - calloc 204 1
TRACE - alloc 204
TRACE - task get current task - return 0x2
TRACE - wifi_thread_semphr_get
TRACE - wifi_thread_semphr_get - return for 2 0x1
TRACE - task get current task - return 0x2
TRACE - mutex_lock ptr = 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - wifi_int_disable
TRACE - wifi_int_disable wifi_int_mux 0x3fc83e38 - return 0
0x3fc83e38 - $d.117
    at ??:??
TRACE - wifi_int_restore
TRACE - wifi_int_restore wifi_int_mux 0x3fc83e38 tmp 0
0x3fc83e38 - $d.117
    at ??:??
TRACE - task_ms_to_tick ms 10
TRACE - queue_send queue 0x3fc88528 item 3fccea28 block_time_tick 160000
0x3fc88528 - _ZN8esp_wifi6compat6common15REAL_WIFI_QUEUE17h297b5537900522ffE.llvm.856754605700107899
    at ??:??
TRACE - queue posting [6, 0, 0, 0, 108, 250, 200, 63]
TRACE - task get current task - return 0x2
TRACE - mutex_unlock 0x3fc83f60
0x3fc83f60 - $d.19
    at ??:??
TRACE - >>>> semphr_take 0x1 block_time_tick 4294967295

Any hints?

[bjoernQ]

Seems the scheduler doesn't get a chance to run. On ESP32-C3 interrupts don't get pre-empted and even if they would, the scheduler is priority 1.

I don't know much about RIOT but I guess it has its own scheduler and synchronization primitives?

In esp-wifi we emulate enough of an RTOS to make things work but I guess it would be better to use esp-wifi-sys and use the RIOT functionality. But again, I really don't know much about RIOT - just guessing

[kaspar030]

Seems the scheduler doesn't get a chance to run. On ESP32-C3 interrupts don't get pre-empted and even if they would, the scheduler is priority 1.

That sounds like a very likely explanation.

I don't know much about RIOT but I guess it has its own scheduler and synchronization primitives?

So RIOT-rs does have its own preemptive scheduler, but no RISC-V support for that (yet). Preemptive scheduling is optional in RIOT-rs, we're using embassy for mostly everything at this stage.

In esp-wifi we emulate enough of an RTOS to make things work but I guess it would be better to use esp-wifi-sys and use the RIOT functionality. But again, I really don't know much about RIOT - just guessing

Well, there's >12k lines of very nice wrapping & integration code in esp-wifi that we don't want to miss out on. 😉
I think for now we'll just go with the esp-hal default (thread mode) executor. Down the line we'll add risc-v support to the RIOT-rs preemptive scheduler, then maybe try to make esp-wifi use that instead of its own emulation...

Anyhow, thanks for looking at this!

[bjoernQ]

Preemptive scheduling is optional in RIOT-rs, we're using embassy for mostly everything at this stage.

Interesting! Thanks for the insights