zephyr-cp/wifi: bound the scan wait and run background tasks

[mikeysklar]

common_hal_wifi_scannednetworks_next() waits with k_poll(..., K_FOREVER) and never runs background tasks.

The wait ends only on a result, a channel_done signal, or ctrl-C. Nothing guarantees any of those arrive. If a scan is abandoned the radio can stop reporting, and the VM thread then parks permanently. Because there is no RUN_BACKGROUND_TASKS in the loop, the supervisor's background callbacks stop too, so the web workflow goes down with the REPL.

Observed on a Silicon Labs SiWx917 DK2605A: the board stopped answering on the console UART and on HTTP while still enumerating to the debugger, and needed commander device reset to recover.

What this does

Polls in 50 ms slices with background tasks between them, and ends the scan if nothing arrives for 10 s.

This matches the other ports. Both run background tasks in the equivalent loop and neither blocks indefinitely:

• ports/espressif/common-hal/wifi/ScannedNetworks.c:39
• ports/raspberrypi/common-hal/wifi/ScannedNetworks.c:67

zephyr-cp was the only one that did.

Hardware tested

SiWx917-DK2605A (BRD2605A), CircuitPython 10.3.0-alpha.4, associated to a WPA2 AP, host on the same LAN.

Four consecutive scans from code.py while a host polled /cp/version.json every 2 s:

scan 0 results 57 uniq 9 secs 8.8
scan 1 results 53 uniq 9 secs 8.9
scan 2 results 51 uniq 10 secs 8.9
scan 3 results 53 uniq 8 secs 9.0

Web workflow: 12 requests during active scanning, 12 x HTTP 200, 0 failures. Before the change the workflow was not served for the duration of a scan.

The 10 s timeout never tripped in normal operation. Results arrive continuously; it exists only so a radio that goes quiet ends the scan instead of parking the VM.

Also built for nordic_nrf7002dk to check the change compiles and links on a board that is in tree today.

Not tested: any other zephyr-cp board on real hardware, AP mode, or the timeout path itself firing (I have not reproduced a driver going quiet on demand).

Cost

No RAM. The deadline is a local, which matters on the DK2605A where the whole CircuitPython heap measures 7888 bytes.

Flash is tight on nordic_nrf7002dk: it sits at 100% of its 944 KB region with 44 bytes free after this change. An earlier version used k_uptime_get() and a printk on the timeout path and overflowed that region by 28 bytes, so the margin there is real and worth knowing about independently of this PR.

Scope

Does not address the duplicate and dropped scan results also visible in the numbers above (51-57 raw for 8-10 unique). That is a separate problem: two 10-deep queues in series, CONFIG_NET_MGMT_EVENT_QUEUE_SIZE and MAX_BUFFERED_SCAN_RESULTS, both of which drop, and it needs a design decision rather than a bug fix.

AI assistance

Written with Claude Code. I ran the hardware, and the numbers above are from the board and the host, not from a model. The comparison against the espressif and raspberrypi loops was checked against the source in this repo.

[mikeysklar]

Superseded by adafruit#11214, which targets adafruit:main directly. Closing this one so there is a single thread for the fix.