Tracking: Pico W / Pico 2 W Bluetooth + Soft_AP DHCP + SSL/TLS HTTP Server via the CYW43439 shared gSPI bus

[tyeth]

Umbrella for the CYW43439 shared-bus Bluetooth work, so nothing here is untracked. Both boards are verified working on hardware: patchram loads over the shared gSPI bus, the controller reports the expected OTP-derived BD_ADDR, and a legacy LE scan returns real advertisers.

Based on the reference implementation in beriberikix/zephyr-cyw43-driver, proposed upstream as zephyrproject-rtos/zephyr#111811 (closed not_planned by the stale bot, not on merit).

State as of 2026-09-09 (rebased onto main 121489fe70)

main moved between the first PRs and now, and two things it did changed this stack:

• Board files moved from boards/<board>.overlay|conf to boards/<vendor>/<board>/board.overlay|conf (d0f27bfc97). All three branches were rebased and their board-file changes relocated.
• main fixed the RP2040 ranges; boot bug itself (ffd62e1c59), so zephyr-cp: restore "ranges" on RP2040 partitions, fixing unbootable images #13 was closed as redundant and zephyr-cp: RP2040 boards are unbootable — overlays drop "ranges" from the partitions node #6/zephyr-cp: stm32wba65i_dk1 overlay has the same missing "ranges" defect as the RP2040 boards #7 closed as fixed upstream. It also resized the settings partition to one aligned 4K sector and pinned nvm/circuitpy to match ports/raspberrypi via a new check_partitions.py parity check. One sector is still one short for NVS (nvs_mount() needs two), so zephyr-cp: enable BLE on the Raspberry Pi Pico 2 W #4/zephyr-cp: enable BLE on the Raspberry Pi Pico W #14 now grow storage to 8K at 0x17e000 out of the code partition and leave circuitpy alone — CIRCUITPY is no longer reformatted by these branches. That placement is build-tested; the hardware runs used the earlier 0x181000 layout.

Pull requests

This repo — stack: main → #5 → #4 → #14

PR	Base	Head	Contents
#5	main	5f0ea1254a	debug UDC thread stack (independent)
#4	#5	bb410ab164	Pico 2 W BLE enablement + settings partition fix
#14	#4	8d2023c6b5	Pico W BLE enablement + settings partition fix
#17	main	74e414d323	README "Board overlay pitfalls" (rework of #13's second commit)
#13	main		closed — ranges; fix landed upstream as ffd62e1c59

Module forks

PR	Contents
tyeth/zephyr#2	USB DPRAM unaligned-access fix (independent)
tyeth/zephyr#1	CYW43 shared-bus HCI driver (stacked on #2)
tyeth/hal_rpi_pico#1	cybt ring-index re-read hardening
tyeth/hal_rpi_pico#2	flash helper RAM placement (independent)
tyeth/hal_infineon#1	Murata-1YN BT coex NVRAM

⚠️ No single hal_rpi_pico branch builds working firmware — both its commits must be combined (currently integration-pico2w-ble, see #12).

Build (post-rebase heads, local zephyr tree with the driver)

	Pico 2 W	Pico W
FLASH	1,146,096 B / 1528 KB = 73.25%	1,181,372 B / 1,564,416 B = 75.52%
RAM	229,144 B / 520 KB = 43.03%	228,044 B / 264 KB = 84.36%
CONFIG_BT / CONFIG_BT_CYW43_SHARED_BUS	y / y	y / y
check_partitions.py	matches raspberry_pi_pico2_w	matches raspberry_pi_pico_w

CI verification

The reviewable PRs still cannot link — #16 — but the build is now verified green in CI for both
boards on ci/pico2w-ble-assets (94bfd47b5f), which sits on top of this stack and adds one
CI-only commit overriding zephyr/hal_rpi_pico/hal_infineon in zephyr-config/west.yml to the
fork branches. That override needs tyeth/zephyr#1 to exist, not to merge, so CI verification is
decoupled from upstream review. The branch is now 0 commits behind main (was 229) and therefore
exercises the current boards/<vendor>/<board>/ layout.

	Pico 2 W	Pico W
run	34287512362 ✅	34287514167 ✅
FLASH	1,146,092 B = 73.25%	1,181,368 B = 75.51%
RAM	229,144 B = 43.03%	228,044 B = 84.36%
artifact (expires 2026-12-07)	8,852,015 B	8,912,451 B

CI matched the local builds to within 4 bytes of flash and exactly on RAM. The Pico W run reports
BOOT_FLASH 256 B 100.00% — a positive check that .boot2 is linked, i.e. the #6 failure mode
tested rather than inferred. This is also the first CI build of the Pico W BLE firmware; previously
only the Pico 2 W had an asset.

⚠️ Dispatching this workflow on a fork needs both --ref and -f branch= — --ref only
selects the workflow file, while the checkout uses the branch input (default main), so a
--ref-only dispatch silently builds main and yields an artifact with no Bluetooth in it.

Issues

Issue	State	Summary
#6	closed	RP2040 boards unbootable — missing ranges (fixed upstream, ffd62e1c59)
#7	closed	Same defect in the STM32WBA overlay (fixed upstream, same commit)
#8	open	BT_EXT_ADV defaults on port-wide, asserting a capability not all controllers have
#9	open	start_scan(extended=) silently ignored
#10	open	boot_out.txt stale version on incremental builds
#11	open	tests / zephyr CI job red — cause not established; being re-evidenced post-rebase on #5's run
#12	open	CI-only west.yml override must not merge; depends on an unreviewed branch
#16	open	BLE branches cannot link in CI: HCI driver absent from pinned zephyr revision (also root-causes #13's missing Build CI run: stale base → no merge commit → no pull_request run). Path now verified green via the override branch — see above
#18	open	release builds lose USB during BLE activity — the #5 UDC stack fix is debug.conf-only (verified on hardware; +unexplained post-scan stall)
tyeth/zephyr#3	open	settings_nvs reads an uninitialized struct when a partition holds zero sectors
tyeth/hal_rpi_pico#3	open	cybt HOST_CTRL cache makes a corruption check vacuous

Seven defects were fixed to get here — only one was mine

Defect	Mine?
Unaligned memcpy into USB DPRAM (M33 widens transfers; M0+ didn't)	no
UDC_RPI_PICO_STACK_SIZE 512 B under immediate logging	no
storage_partition 2 KB & misaligned → NVS -EDOM (now: 4 KB upstream → NVS -EINVAL, still needs two sectors)	no
Stale settings sectors → NVS -EDEADLK	no
flash_enable_write emitted to XIP, called with XIP off → silent core hang	no
cyw43_btbus_init(NULL) — cybt NULL-checks the handle as a sentinel	yes
BT_EXT_ADV on a controller lacking extended advertising	no

Known limits

• Extended advertising is not available on this controller and cannot be made so host-side: the CYW43439 reports the feature bit clear and rejects the commands. The in-tree hal_infineon .hcd is not an alternative — it is the same CYW4343A2 firmware family at an older patch level (...0031 vs pico-sdk's ...0065) and built for UART transport, not the shared bus.
• The georgerobotics cyw43-driver submodule supplies the controller patchram and is under LICENSE.RP, which permits use only alongside Raspberry Pi silicon. Fine for these boards; a blocker for upstreaming to Zephyr proper.
• Measuring anything timing-sensitive on a debug.conf build is unsafe: LOG_MODE_IMMEDIATE formats and transmits in-thread over a 115200 UART and manufactured an apparent 12.5 s HCI stall that does not exist in release builds (first-detection latency ~9,700 ms debug vs 22 ms release).

[tyeth]

Worked from stale upstream, partition range should be fixed, but not settings partition necessarily.

The BLE branches are on the same stale base and will conflict identically. #4, #14 and zephyr-picow-ble all edit boards/rpi_pico_rp2040_w.overlay / rpi_pico2_rp2350a_m33_w.overlay at the old paths. Note main's version still has storage_partition at 0x180800 with 0x800 — so my settings-partition fix is not upstream, only the ranges fix is.

[tyeth]

Body updated with the CI evidence now that both boards build green in CI.

• New CI verification section: ci/pico2w-ble-assets rebased to 94bfd47b5f (0 commits behind main, was 229) so the override branch exercises the current boards/<vendor>/<board>/ layout; both boards green (pico2w, picow) with artifacts and per-board flash/RAM. CI matched the local builds to within 4 bytes.
• Recorded that the override decouples CI from upstream review — it needs drivers: bluetooth: add CYW43 Bluetooth HCI over the shared gSPI bus zephyr#1 to exist, not merge — and the -f branch= dispatch gotcha that otherwise yields a Bluetooth-free artifact.
• Noted BOOT_FLASH 256 B 100.00% on the Pico W as a positive CI check for .boot2, i.e. zephyr-cp: RP2040 boards are unbootable — overlays drop "ranges" from the partitions node #6's failure mode now tested rather than inferred.
• BLE branches cannot build in CI: HCI driver is absent from the pinned zephyr revision #16's row and zephyr-cp: document the overlay pitfalls behind two flash-layout bugs #17's head SHA updated.

Still in flight, not yet reflected: Build CI re-runs on #5 (34282151673) and #17 (34281847143) — these carry the tests / zephyr job that #11 is about, so #11 will be re-evidenced from #5's result rather than the pre-rebase run.

🤖 Generated with Claude Code

[tyeth]

Firmware binaries parked for easy access — zephyr-cp-ble-ci-20260909 (marked prerelease).

GitHub issues can't take file attachments through the API, and the Actions artifacts expire 2026-12-07, so the binaries are on a prerelease instead. Direct links, no login or Actions access needed:

Board	UF2 (flash this)	ELF (gdb)
Pico 2 W	…pico2_w…94bfd47.uf2 · 2,292,224 B	.elf · 22,214,004 B
Pico W	…pico_w…94bfd47.uf2 · 2,363,392 B	.elf · 22,310,200 B

Built from ci/pico2w-ble-assets @ 94bfd47b5f. Both UF2s load from 0x10000000 with the correct family IDs (0xe48bff56 RP2040, 0xe48bff57 RP2350) — independent confirmation .boot2 is linked, versus the 0x00000100 start the pre-fix images had (#6).

⚠️ Flashing either board replaces its contents and reformats CIRCUITPY. These are unofficial test builds from a fork, not a CircuitPython release; delete the prerelease with gh release delete zephyr-cp-ble-ci-20260909 whenever it has served its purpose.

🤖 Generated with Claude Code

[tyeth]

First on-hardware results for the rebased firmware (Pico 2 W, 10.3.0-51-g8031983fc9, flashed over SWD; NET_MAX_CONTEXTS=12, UDC_RPI_PICO_STACK_SIZE=2048, BT_MAX_CONN=4; RAM 236,864 B / 44.48%).

BLE reception confirmed. A 12 s active scan returned 925 advertisement reports from 20 distinct devices, with names resolving (TUYA_, Sinilink-APP, LE-Ninja) — so scan RX and active-scan TX both work. HUB-D754 was not among them on this run, unlike the original bring-up.

Heap: the ELF arithmetic in the port docs is wrong in both directions.

measurement	value
520 KB − static (as documented)	303,336 B — too high, ignores supervisor + GC bookkeeping
gc.mem_free() at a bare REPL	~70,700 B — the initial heap, not the ceiling
cumulative bytearray(8192) to MemoryError	212,992 B — the real capacity
largest single contiguous allocation	between 50,000 and 100,000 B

The GC grows on demand (gc.mem_free() rose to 103,808 B mid-allocation), and port_heap_init() skips its TLSF pool when picolibc's ARENA_SIZE=-1 arena covers the same region, routing allocations through Zephyr malloc. So capacity is chunked: object count is fine, single large buffers are not. Budget against ~208 KB with no object over ~50 KB.

Capability claims verified at the REPL: time.time() → RuntimeError('RTC is not supported on this board'); wifi.radio.start_ap("x") returns without error but ap_active stays False; busio.I2C(scl, sda) → NotImplementedError('Use device tree to define I2C devices'); board.I2C0/I2C1/SPI/UART exist as callables.

Two corrections to what this issue and the port doc imply:

1. CONFIG_BT_MAX_CONN=1 is Zephyr's own default, not a controller limit — nothing in this port set it. A connectionless advertisement-only node protocol is therefore a workaround for a default, not a hardware constraint. Raised to 4 on the Pico 2 W.
2. start_ap being a stub is not a missing driver: airoc_mgmt_ap_enable/ap_disable exist in drivers/wifi/infineon/airoc_wifi.c and are registered in wifi_mgmt_ops. zephyr-cp just never issues NET_REQUEST_WIFI_AP_ENABLE. Zephyr also ships dhcpv4_server.c (CONFIG_NET_DHCPV4_SERVER), so softAP + DHCP + captive portal are hook-up work rather than porting work.

New: #18 (release builds lose USB during BLE activity; the #5 stack fix is debug-only, plus an unexplained post-scan stall).

🤖 Generated with Claude Code

[tyeth]

2026-09-09 (later): softAP, DHCP, TLS, frozen modules, and the scan "stall" — new stack on top of #19

New PRs (stack: #19 → #20 → #21 → #22 → #23)

PR	Head	Contents
#20 zephyr-cp-ble-scan-timeout	3c6020d4d8	the #18 "stall" is Zephyr ignoring scan_param.timeout on the legacy path; deadline enforced from the main thread; console RX wakes the main thread
#21 zephyr-cp-pico2w-sockets-tls	04a55c99da	TCP had never been enabled on these boards (EPROTOTYPE → "Out of sockets"); fd table 16; socketpool finaliser fault fix (zsock_shutdown(0) → jump into cdc_acm_1), errno reporting, accept inherits timeout; ssl server contexts stop demanding a client cert (shared-module, all ports); PEM parsing; p256-m off (mbedTLS sizes the TLS 1.2 premaster from a dummy ECP_MAX_BITS 1 → PSA_ERROR_BUFFER_TOO_SMALL on every ECDHE)
#22 zephyr-cp-pico2w-softap	8ea8f3f75c	start_ap/stop_ap/ap_active/stations_ap/ipv4_address_ap/DHCPv4 server with RFC 8910 option 114
#23 zephyr-cp-frozen-modules	fb700f76bc	FROZEN_MPY_DIRS in circuitpython.toml; Pico W freezes adafruit_ble

Module forks

Branch	Contents
tyeth/zephyr airoc-softap-fixes (3943b1cd7, on top of cyw43-shared-bus-ble)	AIROC ap_enable chanspec bug (every 2.4 GHz channel became 0xd001 → WLAN_BADCHAN, so the AP could never start); AP station events raised without wpa_supplicant; a station's DEAUTH no longer takes the AP interface dormant
tyeth/hal_rpi_pico cybt-ring-index-failure-paths (cc2ea478, merged into integration-pico2w-ble)	cybt_hci_write_buf/cybt_hci_read honour cybt_get_bt_buf_index() failure — a garbage host2bt_in_val made memcpy read off the end of SRAM (bus fault, BFAR 0x20082000, thread bt_tx_processor) after "index still corrupt after 8 reads"

Hardware verification (Pico 2 W AP, ESP32-C6 station): AP up in 0.15 s; C6 gets 192.168.4.2 via DHCP, pings in 5–8 ms; stations_ap tracks join/leave/rejoin; AP survives stop_ap/start_ap and a soft reboot with a station attached; HTTPS served from a PEM RSA-2048 cert over the AP, C6 client receives HTTP/1.0 200 OK in 2.0 s. import adafruit_ble (+2 submodules): 10,384 B heap frozen vs 21,792 B from .mpy.

Sizes

	Pico 2 W (10.3.0-52, this stack)	Pico W
FLASH	1,176,616 B / 75.20 % (was 1,146,504)	1,242,092 B / 79.40 % (was 1,181,368)
RAM	250,240 B / 47.00 % (was 236,864)	238,996 B / 88.41 % (was 228,044)

Of the RAM growth, TCP is ~9.8 KB and the DHCPv4 server + socket service ~3.6 KB. The Pico W at 88 % static RAM is the number to watch.

BT bring-up reliability — worth its own issue. Warm-resetting the RP2350 over SWD (reset run) 12 times on the final image, then _bleio.adapter.enabled = True ~15 s after boot: every boot that did not re-download the patchram (controller still had it) came up instantly; of the boots that did download, 2 of 3 (and 2 of 3 in an earlier run) produced a flood of HCI Hardware error, hardware code: 0 events (~74 at 7 ms intervals) and cybt_get_bt_buf_index: out-of-range index retries, and bt_enable() did not complete within 8 s — with CONFIG_BT_ASSERT=y that ends in Controller unresponsive, command opcode 0x1009 timeout and a halt. The old image (fw -51) showed 0/7 in the same loop; with only 6–7 boots per arm this is suggestive, not proof, that the new image shifts timing. The cybt fix above stops the crash but not the failed bring-up. Suspect: the first HCI traffic right after cybt_fw_download/cybt_wait_bt_ready reading a ring whose indices are not yet valid. Not fixed here.

Open items

• make DEBUG=1 is broken by shell ; in -Dzephyr-cp_EXTRA_CONF_FILE=a.conf;b.conf (runs b.conf as a command, "Permission denied"); the debug fragment is silently dropped.
• mpversion.h is stale in an incremental build dir (zephyr-cp: boot_out.txt reports a stale version on incremental builds #10) — the board reports -51 while running -52 code.
• ci/pico2w-ble-assets needs its zephyr revision moved to airoc-softap-fixes and rebasing onto zephyr-cp: freeze .mpy modules named in circuitpython.toml #23 to CI-verify this stack.

🤖 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