Fatal crash on sta.scan() in UIFlow2 v2.4.4 on Tab5 (MEPC: 0x4ff13582)

[Runaque]

Bug Report: Fatal crash on sta.scan() in UIFlow2 v2.4.4 on Tab5

Summary

Calling sta.scan() on the Tab5 causes a fatal Guru Meditation Error (Load access fault)
every time, crashing and rebooting the device. The crash is 100% reproducible and occurs
on the first WiFi scan attempt regardless of code structure.

Device Information

• Board: M5Stack Tab5
• SoC: ESP32-P4 + ESP32-C6 (via SDIO)
• UIFlow2 Version: v2.4.4
• MicroPython Version: v1.27.0-dirty (2026-04-22)
• IDF Version: v5.5.1-dirty
• OS: Windows 11

Steps to Reproduce

1. Flash UIFlow2 v2.4.4 to Tab5 via M5Burner
2. Open UIFlow2 web IDE, connect via USB
3. Paste and run the following minimal reproduction:

import network
import utime

sta = network.WLAN(network.STA_IF)
sta.active(True)
utime.sleep_ms(500)
print("Scanning...")
results = sta.scan()   # <-- CRASHES HERE
print("Found:", len(results))

4. Device immediately crashes with Guru Meditation Error

Expected Behaviour

sta.scan() should return a list of nearby WiFi networks.

Actual Behaviour

Device crashes with a fatal Load access fault at the same instruction address every time:

Guru Meditation Error: Core 1 panic'ed (Load access fault). Exception was unhandled.

MEPC    : 0x4ff13582   (always identical)
S10     : 0x00000022   (ETIMEDOUT = 34)
S11     : 0x4ff4a4c0   (always identical)
MTVAL   : 0x0000004c

Additional Observations

Crash is always identical

The crash registers are byte-for-byte identical across every run:

• MEPC: 0x4ff13582 — same instruction every time
• S10: 0x00000022 — errno 34 (ETIMEDOUT)
• S11: 0x4ff4a4c0 — same buffer address every time

This indicates a null pointer dereference in the esp-hosted SDIO transport layer
when the ESP32-C6 WiFi coprocessor times out during scan initialization.

WiFi credentials make no difference

Tested both with and without WiFi credentials configured in M5Burner:

• With credentials: MQTT client also crashes alongside the scan
• Without credentials: Same crash, same address, no MQTT involvement

SDIO bus conflict suspected

The Tab5 uses SDIO to communicate with both:

• The ESP32-C6 WiFi/BLE coprocessor
• The SD card slot

The crash signature matches a known SDIO transport timeout in the
esp-hosted component (esp_wifi_remote / SDIO transport layer).

Related community findings

• Arduino WiFi on Tab5 also requires special WiFi.setPins() due to non-standard
  SDIO pin mapping (reported in arduino-esp32 issue #11404)
• Community vanilla MicroPython builds for Tab5 work around this by using a
  different board definition

Crash Dump (representative sample)

MPY version : v1.27.0-dirty on 2026-04-22
IDF version : v5.5.1-dirty
Machine     : M5STACK Tab5 with ESP32P4

Guru Meditation Error: Core  1 panic'ed (Load access fault). Exception was unhandled.

MEPC    : 0x4ff13582  RA      : 0x4ff12970  SP      : 0x4ff2ee10
S0/FP   : 0x0000abab  S1      : 0x0000004c  A0      : 0x0000004c
S10     : 0x00000022  S11     : 0x4ff4a4c0
MCAUSE  : 0x00000005  MTVAL   : 0x0000004c

Crash is Uncatchable from Python

The crash occurs below the MicroPython VM and bypasses Python exception handling entirely.
No try/except block can catch or recover from it. The device hard-crashes and reboots.

UI is Irrelevant

The crash reproduces in a completely minimal non-LVGL environment (see minimal
reproducer above). It has been tested with and without LVGL, with simple scripts,
complex applications, different scan intervals, and different architectural patterns.
None of these variables affect the crash. The UI layer is not the cause.

Root Cause Analysis

MTVAL: 0x0000004c suggests NULL + offset dereference

MTVAL: 0x0000004c (decimal 76) strongly suggests the crash is:

NULL pointer + offset 0x4c = 0x0000004c

Meaning the transport context/session pointer became NULL after a timeout,
and the driver then dereferenced session->field at offset 0x4c without
validating the pointer. This is a classic embedded driver bug in timeout
error-handling paths.

Probable crash sequence

network.WLAN(STA_IF)
  ↓
esp-hosted transport init
  ↓
scan command issued to ESP32-C6 via SDIO
  ↓
SDIO response timeout (S10 = 0x22 = ETIMEDOUT)
  ↓
transport state invalidated / session pointer set to NULL
  ↓
driver dereferences session->field @ offset +0x4c
  ↓
Load access fault at 0x4ff13582
  ↓
Guru Meditation Error / reboot

Possible race condition

This may also be a race condition between SDIO host readiness and
esp-hosted scan command dispatch — timing-sensitive SDIO init races
are extremely common in hosted WiFi architectures.

Additional Diagnostic Tests Performed

WiFi credentials: no effect

• With credentials configured: crashes + MQTT client errors alongside
• Without credentials: identical crash, no MQTT involvement
• Confirms: not a connection state issue

Code architecture: no effect

Tested with minimal scripts, complex applications, different LVGL patterns,
different scan intervals (6s, 10s, 15s), sta.active() checks before scan,
gc.collect() calls, delayed first scan — all crash identically.

Workaround

None available at Python level. The crash occurs inside the C-level
esp-hosted SDIO transport layer and cannot be caught or prevented from MicroPython.

Request

Please investigate the esp_wifi_remote / SDIO transport initialization in the
Tab5 UIFlow2 firmware. Specifically:

1. The timeout error-handling path at 0x4ff13582 does not appear to validate
   the transport context pointer before dereferencing it at offset +0x4c
2. There may be a race condition between SDIO host initialization and the
   first scan command dispatch to the ESP32-C6 coprocessor
3. sta.scan() is a core networking API — if it hard-crashes the device,
   the WiFi transport layer is fundamentally broken for this firmware/device combination

A fix in a future UIFlow2 firmware update for Tab5 would be greatly appreciated.

[Runaque]

Additional finding: Secondary firmware bug — boot sequence crash on cold boot (MEPC: 0x00000006)
While investigating the sta.scan() crash, I discovered a second distinct firmware bug affecting the Tab5 in UIFlow2 v2.4.4.
Description:
On every cold boot, the device crashes during UIFlow2's initialization sequence before any user code runs. The device automatically reboots and boots successfully on the second attempt.
Crash signature:
Guru Meditation Error: Core 1 panic'ed (Instruction access fault). Exception was unhandled.

MEPC : 0x00000006
MCAUSE : 0x00000001
MTVAL : 0x00000006
Key observation:
The stack contains 0x7474696c (ASCII: "litt") pointing to a crash inside UIFlow2's LittlevGL/LVGL initialization sequence — not in user code.
Reproducibility:

100% reproducible on cold boot
Device always self-recovers on automatic reboot
Completely independent of user code — happens before any user application starts

This is a separate bug from issue #94 (sta.scan() at MEPC: 0x4ff13582). Both bugs share the same root environment (UIFlow2 v2.4.4 on Tab5) but occur at different stages and involve different subsystems.

[easytarget]

Have you tried flashing the esp32-c6 (co-processor) with the correct ESP Hosted firmware too?
https://components.espressif.com/components/espressif/esp_hosted/versions/2.12.0/

Currently, if you follow (and debug) the instructions at https://github.com/m5stack/uiflow-micropython and compile uiflow you get:

...
espressif/esp_hosted (2.12.0)
...

In the build log. But I'm pretty certain the C6 is currently flashed with a much earlier version by default. Re-flashing the C6 is (of course) a PITA needing a external flasher. But without matching esp_hosted versions on the P4 and C6 there will be issues.

[Runaque]

...
import os
import sys
import esp
import machine

print("MicroPython:", sys.version)
print("Platform:", sys.platform)
print("Flash size:", esp.flash_size())
print("CPU freq:", machine.freq())

import network
sta = network.WLAN(network.STA_IF)
print("WiFi MAC:", ':'.join('{:02X}'.format(b) for b in sta.config('mac')))

import M5
M5.begin()
print("M5 info:", M5.getBoard())

try:
    import M5Things
    print("M5Things status:", M5Things.status())
    print("M5Things info:", M5Things.info())
except Exception as e:
    print("M5Things:", e)

try:
    f = open('/flash/c6_network_adapter_ota_2.12.0.bin', 'r')
    f.close()
    print("C6 firmware file: present (2.12.0)")
except:
    print("C6 firmware file: not found")
...

This script gives this result!

MicroPython: v1.27.0-dirty (2026-04-22)
Flash: 16MB
CPU: ESP32-P4 @ 360MHz (configured)
WiFi MAC: DC:1E:D5:XX:XX:XX
Board ID: 22 (Tab5)
C6 firmware: 2.12.0 (present)
ESP-Hosted OTA: applied day one via M5Burner
M5Things: offline (no WiFi credentials configured)
Crash: persists regardless of power source

[felmue]

Hello guys

I do not observe a crash on my M5Tab5 (using either UIFlow2.4.4 or UIFlow2.4.5 firmware) running the minimal code mentioned above:

import network
import utime

sta = network.WLAN(network.STA_IF)
sta.active(True)
utime.sleep_ms(500)
print("Scanning...")
results = sta.scan()
print("Found:", len(results))

Output:

True
Scanning...
Found: 25

I wonder if the crash has to do either with the number of WiFi networks found or an SSID with some special characters?

Not sure if it matters, but my M5Tab5 is from the first batch; see version change here.

Thanks
Felix

[Runaque]

---

Update: UIFlow2 v2.4.5 + ESP32-C6 firmware v2.12.6 — Partial Fix

Tested with the new firmware combination:

Component | Version -- | -- UIFlow2 | v2.4.5 (published 2026-05-15) ESP32-C6 firmware | v2.12.6

Results

✅ WiFi scan crash FIXED — sta.scan() no longer causes fatal crash. Continuous scanning confirmed working.

❌ SD card + WiFi SDIO conflict still present:

python

# WiFi scan followed immediately by SD card mount:
Activating WiFi...
Scanning...
Found: 9 networks
Mounting SD card...
E (24944) sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107
SD error: 16  # EBUSY — SDIO bus still conflicted

Ruling out network count and special SSIDs as root cause

The suggestion that network count or special characters in SSIDs caused the original crash can be ruled out:

• An ESP32 Marauder running on a significantly less powerful ESP32 handles hundreds of networks simultaneously — including emoji SSIDs and special characters — without any issues
• The original crash occurred at the C level SDIO transport layer (MEPC: 0x4ff13582) — deep in the ESP32-P4 to ESP32-C6 communication protocol — completely unrelated to SSID content
• The more likely explanation for @felmue observing no crash with 25 networks is simply that a shorter scan places less stress on the SDIO transport timing

Conclusion

The fatal WiFi scan crash is resolved in v2.4.5 + C6 v2.12.6. ✅

The underlying SDIO bus sharing conflict between the ESP32-C6 WiFi coprocessor and the SD card remains unresolved and requires further investigation. ❌

[felmue]

Hello @Runaque

thank you for the update. I am glad to hear you found a fix for the scan issue.

Hmm, looking at the PinMap for ESP32-C6 and SD card indicates no shared GPIOs but rather a separate set of GPIOs for each SDIO. Or am I missing something?

Thanks
Felix

[Runaque]

Hello @felmue

Thank you for looking into the PinMap! You are correct that the ESP32-C6 and the microSD card use completely separate GPIO pins — SDIO2 (G11, G10, G9, G8, G13, G12) for the C6 and a separate set (G39, G40, G41, G42, G43, G44) for the SD card. So the conflict is not at the GPIO level.

The conflict appears to be at the software/driver level — possibly the SDIO controller, DMA engine, or initialisation sequence. When WiFi is deactivated before mounting the SD card and reactivated afterwards, the SD card write succeeds but the system crashes at MEPC: 0x4ff13582 when trying to bring WiFi back up.

Interestingly I also noticed a significant difference in scanning performance between USB power (5V) and the NP-F550 battery (7.4V) — on battery the WiFi radio immediately finds 15+ networks while on USB it finds significantly fewer initially, suggesting the USB power budget throttles the RF power of the ESP32-C6.

The SD card conflict remains something for M5Stack to investigate further at the driver level.

Thanks again for your input!
Runaque.