RGBMatrix at 128px width blanks/freezes when WiFi is active (rp2040/Pico W, CircuitPython 10.3.0)

Start with the attached standalone reproduction and compare its behavior with the reported real-application case on a Pico W, using 64px and 128px RGBMatrix widths with WiFi active. Then trace the RGBMatrix refresh and RP2040 WiFi/network interrupt paths; the issue does not name source files or tests. Done means identifying and fixing the cause so the 128px display remains stable during WiFi polling.

CircuitPython version

10.3.0, adafruit-circuitpython-raspberry_pi_pico_w-en_US-10.3.0.uf2 (built 2026-08-31)

Code/REPL

Full app is ~1074 lines and not publishable as-is, but the change that flips the bug on/off is exactly this:

# works fine, indefinitely:
WIDTH, HEIGHT = 64, 32
matrix = rgbmatrix.RGBMatrix(width=WIDTH, height=HEIGHT, bit_depth=6, ...)

# reliably blanks within under a minute of live operation:
WIDTH, HEIGHT = 128, 32
matrix = rgbmatrix.RGBMatrix(width=WIDTH, height=HEIGHT, bit_depth=4, ...)  # bit_depth
# lowered from 6 only because 6/5 fail to allocate the doubled framebuffer at all

Everything else (WiFi connect, HTTP polling loop, displayio Group/TileGrid/Label usage, auto_refresh=True) is identical between the two runs.

I also tried to build a small standalone repro that doesn't depend on my private application (attached below, test_128_wifi_blanking_repro.py). Across 4 escalating versions — plain wifi.radio.ping(), real adafruit_requests.get() over a SocketPool, added continuously-scrolling text + a full-repaint chasing border ring redrawn every frame, then added gc.collect() after every fetch — none of them reproduced the bug, even after 15+ minutes of continuous observation per version. Only the real application (much more varied endpoint/response-size mix, more frequent displayio.Group child add/remove churn) reproduces it, and does so within under a minute every time I've tried.

Behavior

At width=64 (single HUB75 panel), the display runs indefinitely with zero issues, live WiFi polling included.

At width=128 (two identical 64x32 HUB75 panels chained, single RGBMatrix instance spanning both), with WiFi connected and doing periodic HTTP polling, the display reliably goes fully dark/frozen within under a minute of boot. Critically: this is not a Python-level crash. Confirmed via Get-NetTCPConnection on the host the Pico polls that the Pico's outbound TCP connection was still opening fresh sockets (port number still incrementing) well after the display had already gone dark — the WiFi stack and the main program loop were still running normally. There's no traceback, and the CircuitPython serial console's auto-reload state never changes (i.e. it isn't hitting an unhandled exception path). The RGBMatrix output itself appears to freeze/blank while everything else keeps going.

With WiFi disabled entirely (wifi.radio.connect() never called), the identical width=128 rendering loop runs perfectly stable for many minutes — this isolates the trigger to WiFi activity combined with the wider RGBMatrix's higher PIO/DMA refresh load, not rendering or power alone.

Things ruled out (each tested independently on the real application)

• RGBMatrix buffer memory pressure — confirmed via a real MemoryError at bit_depth=6, fixed by dropping to bit_depth=4, which allocates fine; the blanking still occurs at bit_depth=4 once WiFi is active.
• Scroll/refresh timing (tried several bit_depth/scroll-speed combinations).
• Power supply sag — capping matrix.brightness to 0.6 and 0.5 made no difference.
• EMI from the second panel's own PSU near the Pico's antenna — relocating the board a foot away made no difference.
• CIRCUITPY filesystem/heap fragmentation from repeated soft-reloads — fresh BOOTSEL/UF2 reflashes between attempts made no difference.
• Init order — connecting WiFi before vs. after RGBMatrix() construction made no difference.
• Reducing WiFi request frequency — added real caching to cut actual HTTP traffic by roughly an order of magnitude; still blanked, just as reliably. This is consistent with "crashes at random intervals" rather than a frequency-dependent effect.
• A synthetic repro adding gc.collect() after every network fetch (in case a GC pause was stalling the CPU while RGBMatrix's PIO/DMA refresh was mid-scan-out) — no change, still stable in the synthetic repro (i.e. this alone doesn't explain the difference from the real app either).

Suspected mechanism (not confirmed, offered as a lead)

CircuitPython 9.2.9's release notes document a related, believed-already-fixed bug: "Fix network crashes on Pico W; fixes regression since 9.2.5" (PR #10615, backported as #10617): "#10027 (added in 9.2.5) considerably improved network performance on Pi Pico by using dynamic storage allocation in LWIP. However, it turns out LWIP can do heap operations during interrupts. Thus the operations need to be guarded in critical sections. Otherwise there are storage-related crashes at random intervals."

This board runs 10.3.0, well after that fix landed, so that specific bug should already be fixed. But RGBMatrix at 128px width generates substantially more frequent/longer PIO/DMA interrupts than whatever load the original fix was verified against, and the symptom description ("random intervals") matches closely. Working theory: a similar-class interrupt-timing race is being re-triggered by RGBMatrix's own interrupt pattern specifically at the wider width, not yet identified/fixed for this particular trigger.

Attached: standalone repro attempt (does not reproduce, included for completeness)

See https://gist.github.com/CaptD0nuts/374bd6a7a6d89d5d9ad5e0b46e1b669c — documents 4 escalating attempts, all stable. Happy to share more detail about the real application's structure if that would help narrow this down further, or to run additional diagnostics on the real hardware.