zephyr-cp: fix USB loss under BLE load on the Pico W boards

[tyeth]

Update 2026-10-03: rebased onto CircuitPython 11, and BT_MAX_CONN dropped from this PR

Rebased onto upstream main @ 35210c2e31 (after 11.0.0-alpha.1). This PR is now the single commit 7527914691 ("fix USB loss under BLE load on the Pico W boards"), which touches only ports/zephyr-cp/prj.conf.

• CONFIG_UDC_RPI_PICO_STACK_SIZE=2048 in prj.conf: unchanged. This is still the fix for zephyr-cp: release builds lose USB during BLE activity — the UDC thread stack fix in #5 is debug-only #18's USB loss.
• CONFIG_BT_MAX_CONN=4: removed from this PR. Upstream's prj.conf now sets CONFIG_BT_MAX_CONN=5 for every board, so 4 would have lowered it. The Pico 2 W gets 5. The Pico W sets 2 in its own board.conf (zephyr-cp: enable BLE on the Raspberry Pi Pico W #14, b610e43) to give heap back.
• So the section on BT_MAX_CONN=4 and the "Cost" figures below no longer describe this PR. The title still says "allow four BT connections", which is now stale.
• The base branch zephyr-cp-pico2w-net-contexts has no PR. It sits on zephyr-cp: enable BLE on the Raspberry Pi Pico W #14 plus the CI-only west.yml override commit, so zephyr-cp: fix USB loss under BLE load on the Pico W boards #19–zephyr-cp: freeze .mpy modules named in circuitpython.toml #23 carry that override too.

---

Fixes #18, and lifts the connection limit that shaped the node protocol in tyeth/deepsleep_espnow_wifi_and_ble_env_collector#11.

Stacked on zephyr-cp-pico2w-net-contexts (twelve network contexts), which is itself on ci/pico2w-ble-assets.

CONFIG_UDC_RPI_PICO_STACK_SIZE=2048 moves to prj.conf

#5 added this to debug.conf only, so every release image kept Zephyr's 512-byte default and the usbd@50110000 overflow was never actually fixed for the images we flash. On hardware the board drops off USB partway through a _bleio scan — CDC port and CIRCUITPY volume both gone, USB device/stack error on reset, recovered with an SWD reset run.

Verified: with the fix, a 12 s active scan producing 925 advertisement reports from 20 distinct devices completes with USB enumerated throughout. The same workload took the bus down before.

CONFIG_BT_MAX_CONN=4 on the Pico 2 W

BT_MAX_CONN=1 was Zephyr's default — nothing in this port set it, and the CYW43439 is not the constraint. At 1 the hub can hold a single peer, which is what pushed the collector's node protocol to connectionless advertisement broadcasts with no delivery confirmation. Four lets nodes connect and sync.

Pico W is deliberately left at the default: with ~208 KB of usable heap on the Pico 2 W versus ~42 KB there, the RP2040 is node-only anyway.

Cost

RAM 231,112 → 236,864 B (43.40% → 44.48%), flash +408 B. Measured, not estimated.

Not fixed here

The post-scan stall in #18 — execution blocking on the first statement after the scan window closes until Ctrl-C. Different cause, unestablished, and unaffected by this change.

🤖 Generated with Claude Code

[tyeth]

Correction to my earlier evidence in this thread.

I described the USB verification as "a 12 s active scan producing 925 advertisement reports". The scan duration was wrong: timeout= was being silently ignored on the legacy scan path, so that run was ~33 s at ~28 reports/s, not 12 s (#18, now fixed by #20). I also characterised the behaviour afterwards as a "post-scan stall" — nothing was stalled; the scan had never ended, and the KeyboardInterrupt simply landed on the statement after the loop.

What still holds: USB stayed enumerated for the whole run with UDC_RPI_PICO_STACK_SIZE=2048, where the same workload previously took the board off the bus. That was the claim being tested, and a longer scan makes it a stronger result, not a weaker one. The report count and distinct-device count were accurate.

Two of my other framings in this thread were also wrong, per the bench work in #21/#22:

• I said start_ap was "a hook-up job, not a driver port" because airoc_mgmt_ap_enable exists. The driver was in fact broken: it composed band/bandwidth bits into a chanspec that WHD's whd_wifi_init_ap() re-wraps with CH20MHZ_CHSPEC(), turning channel 1 into 0xd001 (5 GHz) and failing every AP start with WLAN_BADCHAN. Fixed on the zephyr fork, not in CircuitPython.
• I said "ssl/socketpool are already enabled" as though TLS would work. CONFIG_NET_TCP had never been enabled for these boards, so no SOCK_STREAM socket had ever succeeded — it failed with EPROTOTYPE, misreported as "Out of sockets". Three further defects had to be fixed before a handshake completed.

🤖 Generated with Claude Code