Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#11,362 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, python
Ambito
embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug displayio rp2040
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.

Lingua principale
C
Stelle
4.6k
Fork
1.4k
Merge medio
1g 7h
PR unite (30g)
147

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di adafruit/circuitpython

Tutte le issue di adafruit/circuitpython

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.