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

Activity

1. tyeth commented on Sep 8, 2026

   

   tyeth

   on Sep 8, 2026

   OwnerAuthor

   More actions

   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.
2. tyeth commented on Sep 8, 2026

   

   tyeth

   on Sep 8, 2026

   OwnerAuthor

   More actions

   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
3. tyeth commented on Sep 8, 2026

   

   tyeth

   on Sep 8, 2026

   Last edited by tyeth

   OwnerAuthor

   More actions

   Firmware binaries parked for easy access — v-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 v-zephyr-cp-ble-ci-20260909 whenever it has served its purpose.

   🤖 Generated with Claude Code

   ---

   Edit: the release tag was renamed to v-zephyr-cp-ble-ci-20260909 and the links above updated. A tag not starting with v is picked up by py/version.py (git describe --first-parent --match "[!v]*"), which broke every pristine build and both CI asset builds on ci/pico2w-ble-assets with "Cannot determine version". The v- prefix makes it invisible to that matcher.
4. tyeth commented on Sep 9, 2026

   

   tyeth

   on Sep 9, 2026

   OwnerAuthor

   More actions

   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
5. tyeth commented on Sep 9, 2026

   

   tyeth

   on Sep 9, 2026

   OwnerAuthor

   More actions

   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
6. tyeth commented on Sep 9, 2026

   

   tyeth

   on Sep 9, 2026

   OwnerAuthor

   More actions

   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
7. tyeth

   changed the title [-]Tracking: Pico W / Pico 2 W Bluetooth via the CYW43439 shared gSPI bus[/-] [+]Tracking: Pico W / Pico 2 W Bluetooth + Soft_AP DHCP + SSL/TLS HTTP Server via the CYW43439 shared gSPI bus[/+] on Sep 9, 2026
8. tyeth commented on Sep 10, 2026

   

   tyeth

   on Sep 10, 2026

   OwnerAuthor

   More actions

   Warm-reset BLE bring-up: measured, and the previous conclusion retracted. Full evidence in #25.

   The failure mechanism is real and gdb-evidenced (BT shared-memory base reads 0 → HCI command to backplane address 0 → 10 s timeout → BT_ASSERT halts the kernel → USB drops). But the reported 19% → 50% → 100% warm-reset failure rate, and its attribution to cumulative controller degradation needing a physical power cycle, do not hold. On the unfixed image, probe pinned, no power cycle performed: 45/45 successful bring-ups — 16/16 software warm resets with no debugger, 16/16 one-shot SWD resets, 13/13 with a persistent debugger and deliberate mid-boot halts. p ≈ 1e-4 against a 19% rate.

   My own follow-up hypothesis — that a persistent debugger desynchronised the shared bus — was also tested and rejected by that third arm. The original numbers are unexplained; the leading untested candidate is an unpinned cmsis-dap.cfg with two probes attached, so resets may have been driven into the other board.

   Landing anyway as safety hardening, explicitly not as a reliability fix: tyeth/zephyr#4 and tyeth/hal_rpi_pico#4 (validate the base, source it via WHD, bounded retry, return a retryable OSError instead of halting — 8 halts → 0). #24 (make DEBUG=1) is unrelated and validated.

   Bench practice worth adopting: never measure hardware reliability with a debugger attached, and always pin adapter serial when more than one CMSIS-DAP probe is present.

   🤖 Generated with Claude Code
9. tyeth commented on Sep 10, 2026

   

   tyeth

   on Sep 10, 2026

   Last edited by tyeth

   OwnerAuthor

   More actions

   Upstream escalation index

   Every defect found in this work that belongs to an upstream project now has an issue on the corresponding fork, so upstreaming later is a matter of copying the issue and pointing at the branch. Only the esp-idf one has been submitted upstream so far — the rest say so explicitly on the issue.

   Index current to 2026-10-03; covers tyeth/circuitpython #4–#30 and all fork issues. Updated after the stack was rebased onto upstream main @ 35210c2e31 (after 11.0.0-alpha.1). Each CircuitPython defect below was re-checked against that main and is still present upstream. Fork fix SHAs are the post-rebase ones. Firmware: v-zephyr-cp-ble-ci-20261003.

   Fixed upstream since the last update

   ours	upstream	what happened here
   #24 make DEBUG=1 (unquoted EXTRA_CONF_FILE)	adafruit#11423 (d9682758b5)	commit dropped in the rebase; #24 closed
   #20's second commit (console RX wakes the main thread)	adafruit#11448 (2b8a218385)	commit dropped in the rebase; #20 is now the scan-timeout fix alone
   #19's CONFIG_BT_MAX_CONN=4	upstream prj.conf now sets CONFIG_BT_MAX_CONN=5 for every board	dropped (4 would have lowered it). The Pico W sets 2 in its own board.conf to give the heap back (#14, b610e43da2)

   zephyrproject-rtos/zephyr

   fork issue	defect	our fix
   tyeth/zephyr#3	settings_nvs: sector_cnt==0 with rc==0 treated as success, then an uninitialised hw_flash_sector is read (saw fs_size=537016640)	avoided by sizing the partition correctly (now 8K at 0x17e000 on top of upstream's Adaboot layout, #4/#14)
   tyeth/zephyr#5	udc_rpi_pico: unaligned memcpy to/from USB DPRAM faults on Cortex-M33 (M0+ escapes it by byte-copying)	tyeth/zephyr#2
   tyeth/zephyr#6	udc_rpi_pico: default thread stack of 512 B overflows under concurrent USB + radio load; board leaves the USB bus	#19 (prj.conf)
   tyeth/zephyr#7	udc_rpi_pico: Endpoint busy logged as an error during normal CDC transmission (1400+ line bursts)	none — cosmetic unless LOG_MODE_IMMEDIATE
   tyeth/zephyr#8	airoc: ap_enable builds a chanspec that whd_wifi_init_ap() re-wraps, so every softAP start fails WLAN_BADCHAN; plus a station DEAUTH taking the AP interface dormant	airoc-softap-fixes
   tyeth/zephyr#9	BT host: legacy scan path silently ignores bt_le_scan_param.timeout, so scans never end	#20 (host-side deadline)
   tyeth/zephyr#10	mbedTLS: TLS 1.2 premaster sized from dummy ECP_MAX_BITS when p256-m serves P-256 → PSA_ERROR_BUFFER_TOO_SMALL	#21

   The tyeth/zephyr override branches (cyw43-shared-bus-ble, airoc-softap-fixes) are still based on 62e7a3764b, 9 commits behind upstream CircuitPython's Zephyr pin 70f1a63cc8. Those 9 commits touch none of the same files, so a rebase should be clean. It hasn't been done yet.

   zephyrproject-rtos/hal_rpi_pico (ultimately raspberrypi/pico-sdk)

   fork issue	defect	our fix
   tyeth/hal_rpi_pico#3	cybt: HOST_CTRL reads come from a software cache, making the corruption check in cybt_toggle_bt_intr() vacuous	none — recorded
   tyeth/hal_rpi_pico#6	cybt: pico-sdk assert() is live in the Zephyr build and panics the kernel on bring-up failure, pre-empting the error return already behind it	tyeth/hal_rpi_pico#5
   tyeth/hal_rpi_pico#7	hardware_flash: static inline helpers can be emitted to flash and called with XIP disabled → silent hang, unrecoverable over SWD	tyeth/hal_rpi_pico#2

   The hal_rpi_pico and hal_infineon override branches still sit directly on the revisions upstream pins (266394b0f2, 13e4b3cd70), so they match without a rebase.

   adafruit/circuitpython

   fork issue	defect	our fix	upstream main @ 35210c2e31
   #26	shared-module/ssl: a server-side SSLContext wrongly requires a client certificate (-0x7480), unlike CPython. Affects all ports	ba0232c35a on #21's branch (was cbcfeec077)	still present: SSLSocket.c sets MBEDTLS_SSL_VERIFY_REQUIRED for a server side too
   #27	ports/zephyr-cp _bleio: after bt_enable() fails in bt_hci_open(), nothing clears BT_DEV_ENABLE, so the retry takes -EALREADY as success — settings_load() then runs on an uninitialised host, yielding a random static BD_ADDR and, when the GATT db hash differs, a k_work NULL handler → UsageFault → kernel halt (USB drops)	none yet — fix proposed in the issue (clear BT_DEV_ENABLE on failure; accept -EALREADY only when bt_is_ready(); never fall back to a random identity)	still present: bleio_adapter_ensure_stack_ready() accepts -EALREADY, then calls settings_load()
   #28	py/version.py tests "CP_VERSION" in os.environ (presence, not truth), so an empty CP_VERSION exported by .github/actions/mpy_cross aborts "Set up mpy-cross" with Cannot determine version. Bites any board with frozen modules whose caller passes an empty cp-version	393be068ab on ci/pico2w-ble-assets (was 7ba84d8936) — one line, os.environ.get("CP_VERSION"). Both boards green with it on the rebased stack (37126091753, 37127295820)	still present: if "CP_VERSION" in os.environ:

   #26 is still the best standalone upstream candidate — port-independent, small, and it makes socketpool + ssl unusable as a TLS server on any board. #28 is the next easiest: one line, no port knowledge needed, already proven in CI here. #27 is zephyr-cp-only and larger, but it is a hard kernel halt and a silently wrong BLE identity, so it should not sit on the fork indefinitely.

   Bench note, deliberately not upstreamed: #29 — ESP32-C6 Nordic UART service invisible to Windows clients. Filed against the fork because it presents as a CircuitPython bug and is not one: Windows serves a cached GAP+GATT-only attribute table keyed on the BLE address, and changing the address makes the service appear on unchanged firmware. There is a possible upstream angle — the peripheral advertises robust caching (0x2B3A/0x2B29), so if _bleio changes its service set between boots (e.g. the CIRCUITPY{mac} BLE workflow on one boot, the app's services on the next) without a Service Changed indication or a database-hash bump, the board is arguably at fault. Not upstreamable until that is confirmed on a C3/S3, so it stays here for now.

   zephyrproject-rtos/hal_infineon

   fork issue	defect	our fix
   tyeth/hal_infineon#2	Murata 1YN NVRAM does not enable BT coexistence on the shared gSPI bus (also records why the in-tree .hcd is not a usable patchram alternative)	tyeth/hal_infineon#1

   espressif/esp-idf

   fork issue	defect	our fix
   tyeth/esp-idf#1	lwip/dhcpserver.c fails to build with DHCPS_DEBUG=1 (%x vs u32_t)	submitted upstream — espressif/esp-idf#19074 (still open, tracked as IDFGH-18269)

   Not upstream — ours to keep

   #8 (BT_EXT_ADV default), #9 (start_scan(extended=) ignored), #10 (stale boot_out.txt), #12 (CI-only west.yml override), #16 (CI cannot link until tyeth/zephyr#1 merges), #25 (warm-reset bring-up: mechanism real, trigger unexplained). #30 is the env-collector's frozen-library PR against the ESP32 bench firmware, not an upstream candidate.

   Closed since: #6, #7 (ranges; fixed upstream by ffd62e1c59), #11 (tests / zephyr green again, likely an upstream fix), #13 (redundant), #18 (USB loss fixed by #19; its "residual stall" explained by #20), #24 (landed upstream as adafruit#11423).

   🤖 Generated with Claude Code
10. tyeth commented on Sep 10, 2026

    

    tyeth

    on Sep 10, 2026

    OwnerAuthor

    More actions

    https://github.com/tyeth/circuitpython/tree/zephyr-cp-rtt-console for RTT mode, both Pico+Pico2w
11. tyeth-ai-assisted commented on Oct 24, 2026

    

    tyeth-ai-assisted

    on Oct 24, 2026

    Collaborator

    More actions

    Upstream escalation index and alpha.2 refresh

    This updates the 3 October index. Fork fixes, upstream resolutions and hardware evidence are distinguished below. A fork PR is not an upstream submission, and a successful build is not a physical-board pass.

    As checked on 24 October 2026, the newest published prerelease is 11.0.0-alpha.2 (21 October); stable is 10.3.1. There is no published alpha.3 (official releases). The current work is rebased on alpha.2, with exact dependency pins recorded below.

    Integration branches and qualification

    • ESP CircuitPython #31: alpha.2 rebase, frozen Env Hub libraries, board layouts and complete-chain TLS buffers.
    • Pico CircuitPython #32: alpha.2 rebase and the paired Zephyr/HAL fixes.
    • Zephyr #11: release-pinned integration including shared-bus HCI, AP, USB compatibility, startup cleanup, settings geometry and RX lock scope.
    • HAL Infineon #3: atomic backplane-window and bus-power transitions.
    • Collector #37: complete certificate-chain handling, soak tooling, Chrome WebMCP and the separate opt-in mobile Prompt API fallback.

    Current open draft heads: ESP CP e46718f34b32, Pico CP 3254e272628e, Zephyr 5bf4230db7fe, HAL Infineon 7f93dc606751, and HAL Pico #8 de12fc2a0f75. Collector source and evidence are at b62ba7c2a4f5.

    The ESP32 V2, bare C6 and Metro S3 have bounded physical checks on the ESP-NOW fix; C5/C61 now run the later e467 board-specific images, with separate post-reset radio checks and C5 trusted HTTPS/asset verification. Feather S3 was removed: its newer image is built but not physically requalified. Both Picos remain on original 9e153 production images after temporary candidate tests and verified restoration. Normal startup/radio, forced retry and targeted MSC-error checks now have evidence on both Picos; general USB reliability is still unresolved.

    Three completed eight-hour runs cover earlier pinned builds: C5/C61 application delivery (236 true wakes), ESP32 V2 radio (960 cycles), and HTTPS (240 checks). Later firmware does not inherit these passes. The original Pico W 140-cycle failure remains failed. Actual Pico W node startup passes two MCU resets, stable identity and repeated simulated-sensor advertisements; bounded receiver delivery now passes as described below; real SCD41 sampling remains unverified.

    Pico 2 hub testing found two distinct defects: a positional start_scan argument (fixed with prefixes=, three host regressions) and first-use advertising/scanning identity mismatch (Zephyr #12, fixed by #11). The earlier revised diagnostic passes 44-file readback, MCU startup, twelve scan starts and twelve HTTP JSON checks, followed by byte-exact original 4 MiB restoration and independent postflight. Those diagnostic scanner samples contain no error but zero received packets; the subsequent normal-image paired result follows. Earlier application failures, the separate recovery after USB loss and the minimal diagnostic missing its BEGIN marker remain recorded failures. This is bounded hub startup/scan/HTTP qualification, not end-to-end delivery, real sensors or a long soak. Evidence.

    Both normal Pico builds pass at CP 3254e272628e / Zephyr 5bf4230db7fe, with clean dependencies and no firmware diagnostic hooks. The normal Pico 2 image now passes actual Pico W node advertisement reception: three changing synthetic readings match captured node UART values, with RSSI, receive counts 4/5/6 and twelve HTTP checks. Both original storage images restore byte-exact; original board/version/files and independent postflight pass. Original Pico 2 radio health is explicitly not certified: its earlier import wifi timeout also reproduces without the sender. Earlier failed attempts remain failed. The new normal Pico W image remains build-only here, and production retains restored 9e153. Paired evidence and limits.

    All nine ESP board variants and both Pico variants have build evidence. Physical qualification must be read from the results above, not inferred from the eleven-build total. Earlier failed/interrupted runs remain preserved. In particular, the a0c1485cf5 Pico W run failed after 140 cycles / 4,236.05 seconds; the later RX lock fix proves a source defect but does not, without a live thread capture, prove the cause of that particular physical stall. Earlier binaries built from stale dependency checkouts retain their actual-source attribution.

    Confirmed upstream resolutions

    Fork item	Upstream resolution	Disposition
    Zephyr #5, unaligned USB DPRAM access	c2d5de2a0ac6	Fork tracker closed. Current upstream uses aligned word transfers plus byte tails. The older alpha.2 dependency still needs its equivalent compatibility patch.
    Zephyr #7, normal transfer queuing logged as an error	2f0bc11264a8	Fork tracker closed. This removes the reported XFER_NEW queue-path log; a different completion-path log remains.
    HAL Pico #7, flash helpers executing with XIP disabled	74cc3dfda63e	Fork tracker closed. All three helpers are placed in RAM, an equivalent resolution to the fork's forced-inline patch. The release-pinned older dependency still carries its compatibility fix.
    CP #24, DEBUG quoting	Adafruit #11423	Duplicate omitted from the alpha.2 rebase.
    Console-wake part of CP #20	Adafruit #11448	Duplicate omitted; the separate scan deadline remains carried.

    The historical sleep-memory reload report is already resolved by Adafruit #11274; its merge is an ancestor of alpha.2. No duplicate patch is needed. A current C5 physical control now preserves all 4,096 bytes across three verified VM reloads with POWER_ON reset reason and restores the original contents. Its final combined cleanup assertion fails; separate read-only checks confirm original port/inventory/import state without recovery mutation. This is not fake/true-deep-sleep or battery-retention qualification. See Collector docs/c5-sleep-memory-reload-2026-10-23.md at ffe24af5c051911310b940239fe85a359ad7149b.

    The global BT_MAX_CONN=4 override was also dropped because upstream sets 5. Pico W's board-specific limit of 2 remains a separate memory choice. The three newly closed trackers above were checked against upstream source and commit ancestry, not merely matching issue titles.

    Reproduced candidates and minimal tests

    These are still fork candidates unless an upstream PR is explicitly named. Commands assume the configured checkout and its dependencies; use fresh test output directories.

    Tracker / fix	Minimal reproduction	Fresh evidence and limits
    Zephyr #12, first scan after connectable advertising; fix 5bf4230db7fe in #11, pinned by CP #32	Disable BLE workflow, MCU reset, start a simple connectable legacy advert before any scan, then request a passive one-second scan (.1/.05-second windows). Baseline reports errno22/HCI0x12; scan-before-advertising masks it. Exact script: Collector tools/reproduce_zephyr_scan_order.py. Unit regression: west twister -T tests/bluetooth/host/id/bt_id_set_scan_own_addr -p unit_testing.	Track implicit identity use and select the actual advertiser identity. Five unit configurations: baseline19 pass/1 fail/35 skip, candidate20 pass/0 fail/35 skip. Revised diagnostic full hub passes twelve scan starts and twelve HTTP checks, full original restoration and postflight. Nondefault identities have unit coverage; physical comparison uses public identity. Earlier failed captures remain failed. The separate normal-image paired test subsequently verifies real node reception; no current-upstream-main hardware claim.
    CP #43, silently acknowledged MSC block errors; CP #32 5f73172d46	On an unmounted backed-up disk, pause autoreload; send SG_IO WRITE(10) 2a000000000000000800 using the existing first 4096 bytes. Inspect SCSI status/sense, then verify the complete disk. Use LBA 1 as a valid same-data control.	Both Picos report false GOOD on 9e153 and CHECK CONDITION / WRITE ERROR (03/0c/00) on the candidate. Valid writes and three free-sector spans restore exactly. Native bounds/media/cache/error checks pass 56/56 versus 34 baseline failures. Synthetic-MBR multi-sector rejection remains intentional. Pico 2's job failed later at a ROM identity guard before firmware restoration writes; the MSC disk had already been restored exactly. Separate recovery verified original code/full expected flash and radios. Preserve both records. Exact evidence and limits.
    CP #40, station lifecycle stubs; fix 9e153ad624 in #32	Connect a station, call wifi.radio.stop_station(), inspect connection/IP and independently check AP departure. Repeat stop and reconnect; then repeat while the board also hosts an AP.	Earlier bodies were no-ops. The fix passes 46 native checks and physical Pico W/Pico 2 lifecycle, disabled-start and AP-preservation controls. Evidence.
    ESP-NOW #9816, partial packet publication; fix ea06dcb44e in #31	Run python3 tools/check_espnow_rx_lock.py against the pinned baseline/candidate. Interleave the reader after header publication, before payload completion; then exercise two real threads. Physically send numbered, checksummed packets from an S3 to an ESP32 V2.	Actual-source baseline fails; candidate passes ten groups including 20,000 concurrent packets with exact receive/drop accounting. Physical baseline reproduces invalid-buffer; candidate passes the identical channel/integrity comparison. Broadcast drops persist; C6 bounded AP/BLE traffic now measured 93/100 exact round trips with seven sender failures and no corrupt received payloads. Multi-sender and sustained-load qualification remain open. Evidence.
    Pico DHCP service starvation; fix 6b117bdce5 in #32	Start an AP, connect a peer, and compare priority 15 with 0 while the interpreter runs a 15-second busy loop.	Same-source control fails at 15, acquires a lease in 4.467 seconds at 0. Both Pico production boards subsequently pass channel 1/6/11, DHCP/ping and departure. The separate ESP connect-timeout report remains #7557.
    CP #28, empty version override; fix in #32	In a tagged checkout compare CP_VERSION= python3 py/makeversionhdr.py /tmp/version.h with env -u CP_VERSION python3 py/makeversionhdr.py /tmp/version.h. Empty must fall back to Git.	Four header-generation cases pass. Current upstream's presence-only check remains affected.
    CP #26, default TLS server demands a client certificate; fix in #32	Create a default server context and load only its own certificate/key. Connect a normal client without a client certificate. Run the native source-policy fixture.	Eight cases / fourteen real TLS handshakes. Alpha.2/current upstream returns -0x7480; the carried fix accepts the client. Explicit load_verify_locations() still requires a trusted client certificate. Clients still reject untrusted servers and wrong hostnames. This exercises actual shared-module policy with real cryptography over memory transport, not every port's interpreter/network stack.
    CP #27, BLE startup retry; HAL Pico #8, CP #32	Inject ready/buffer/awake error returns after successful hardware work; require Wi-Fi after each, a clean retry, one firmware download across four attempts, stable address and three scans.	Original physical retries hit HCI Read_BD_ADDR completion timeout. The ready-state download guard passes the matched controls on both Pico W and Pico 2 W; the 17-case source fixture passes versus 8/17 on baseline. Both normal builds and startup/reenable controls pass. All completed runs restore original firmware. Natural electrical faults and end-to-end workflow client transfers remain unqualified. Pico W source/reproducer, Pico 2 controls.
    CP #9, unsupported extended scan request; fix in #32	Start an ordinary scan, request start_scan(extended=True), consume the original scan, then start another ordinary scan.	Twenty-six actual-source checks plus two simulator boards and Pico W physical checks pass. The API now raises NotImplementedError before replacing the scan; extended advertising is not implemented.
    CP #10, stale version header; fix in #32	Build, change Git revision or CP_VERSION, and rebuild without cleaning. The version must refresh; unchanged output must retain its timestamp.	Both incremental-header regressions pass. This is separate from the empty-override defect.
    Zephyr #3, zero-sector NVS/ZMS geometry; fix in #11	Place a 2 KiB settings partition at a 2 KiB offset on 4 KiB erase-page flash. Run west twister -T tests/subsys/settings/sector_geometry -p native_sim/native/64. Initialization must reject zero sectors before reading geometry or mounting.	Six scenarios / twelve cases pass across NVS and both ZMS modes; all three malformed controls fail before the fix. Current upstream still lacks the guard.
    CYW43 RX allocation/delivery holds the shared bus; fix in Zephyr #11	Run python3 tests/drivers/bluetooth/cyw43_rx_bus_contention.py --root . --baseline 353bcd30f76e1fa140291540dde20334e952e0e6, then omit --baseline. A consumer requiring the bus must progress while host RX allocation waits.	Seven of twelve baseline cases fail; all twelve fixed cases pass. Controller ring checks/reads remain locked; host allocation/delivery happens unlocked. Compiled Pico ELFs independently confirm the ordering.
    Shared backplane-window and bus-power races; fixes in HAL Infineon #3 + Zephyr #11	In the HAL checkout run python3 tests/test_whd_backplane_lock.py and python3 tests/test_whd_bus_power_lock.py. Inject competing owners between window selection/access and during sleep/wake transitions.	Actual vendor-source harnesses reproduce the original errors and pass 28 window / 40 power cases after fixing them. The paired Zephyr wake guard passes 25 cases. These source regressions do not establish a physical stall's exact cause.
    Zephyr #10, p256-m premaster buffer; configuration workaround retained in #32	Run the native PSA fixture with p256-m enabled and disabled. Compare actual MBEDTLS_PREMASTER_SIZE with an explicit 32-byte control.	p256-m gives a one-byte TLS buffer and real ECDH returns PSA_ERROR_BUFFER_TOO_SMALL (-138); its 32-byte control passes. Disabling p256-m gives 32 bytes and both cases pass. Relevant tested TLS/ECP header blobs match current upstream. This is component evidence, not a new network handshake.

    The earlier 7d4ef1aac7 / 7379648278 integration passed all ten BLE scan tests across nRF5340/nRF54LM20 and all 85 build-tool tests, with actual clean pins checked before and after. Nordic simulator tests do not exercise the CYW43 hardware driver. The audit links exact manifests, source blobs, output hashes and reproduction boundaries.

    Carried reports needing additional targeted evidence

    Tracker	Minimal next reproduction / current disposition
    Zephyr #6, USB stack	Matched 512/2048-byte worker builds use at most 260 bytes during the bounded CDC/MSC/radio workload; no 512-byte shortage reproduced. Later targeted MSC write tests now pass on both boards, including S31 transport, as described under #43. This does not qualify idle re-enumeration, 64 KiB USB/IP reads or sustained application traffic. Stack comparison.
    Zephyr #8, AIROC softAP channel/events	Start CYW43439 softAP channel 1 through the non-supplicant management path, inspect the argument to whd_wifi_init_ap, then associate/deauthenticate a station. The fork passes the bare channel and handles AP events; upstream source still constructs the problematic chanspec. Physical results must be read separately above.
    Zephyr #9, ignored legacy scan timeout	Standalone Pico 2 diagnostic now reproduces two passive .timeout=300 (3 s) scans still receiving at 6 s, with 23/26 reports after 3.5 s and no callback. Unlimited control and explicit-stop checks pass. Current upstream 76280bce still omits the field, but differs in filter-policy code; it was source-audited, not flashed. Production restored exactly after a separately recorded ROM-handshake recovery. Minimal app: Collector tools/repro_legacy_scan_timeout; evidence docs/legacy-ble-scan-timeout-2026-10-23.md. The CP host deadline remains the workaround; no Zephyr fix implemented.
    HAL Pico #3, cached HOST_CTRL	Instrument hardware reads and simulate a lost HOST_CTRL write. Compare the cache-based read with hardware. Fresh actual-function fault injection confirms four cache controls, including lost-write cache/hardware divergence; no physical lost write or production cache-policy fix is claimed. See the coverage ledger and tools/check_pico_btbus_reports.py in Collector #37.
    HAL Pico #6, assertions before error returns	Native and physical forced ready/buffer/awake error returns pass. Retry then exposed repeated patch-RAM download, addressed by HAL #8. Both Picos now pass the software-error retry controls and normal startup controls. Electrical-fault recovery remains unqualified; successful software injection is not proof of it.
    HAL Infineon #2, coexistence resources	Inspect the selected CYW43439 Murata 1YN NVRAM and loaded WLAN/CLM assets, then run concurrent Wi-Fi/BLE. Upstream's text asset still has btc_mode=0; HAL #1 supplies the carried resource changes, extended by #3.
    ESP-IDF #19074, from fork #1	Build the DHCP server with DHCPS_DEBUG=1 on ESP32-C6/S3: %x receives u32_t and trips -Werror=format. The submitted fix uses PRIx32. Refreshed 24 October: still OPEN/unmerged at 60bf48d497c086d5b26f123f49df1401c523b727.

    Project choices and corrected claims

    Frozen application libraries (#30, integrated through ESP #31), board flash layouts, CI override plumbing (#12/#16), default extended-advertising configuration (#8), and memory limits remain project integration work. The unsupported extended=True API-contract bug is now explicitly handled as described above; this does not provide extended advertising.

    The old warm-reset failure-rate claim for #25 was retracted after 45/45 warm resets succeeded; its trigger remains unproven. #29's possible GATT-cache/Service Changed angle remains unconfirmed, so it is not presented as an established upstream defect.

    Chrome WebMCP and the mobile Prompt API fallback are separate paths. Android emulator testing retained the 512,096,557-byte model across reload, Chrome restart and emulator restart, then ran inference without fetching weights again. This validates the JavaScript/OPFS fallback; it does not claim native Android ML Kit/AICore support or measured physical-phone performance. Storage clearing or browser eviction can require another download.

    Bench fixes and remaining USB failures

    • Bridge #23 / PR #24: injected partial interface-claim failure leaked earlier claims. Actual-source checks pass 24 cases versus 163 baseline failed assertions. Installed selective-claim PR #25 passes both dual-CDC attachment orders. This is not full composite endpoint-capacity qualification.
    • Controller #1 / PR #2: inject HTTP 503 during disappearance polling, or accept OFF without changing the observed port. The old code falsely succeeded. The fix requires observed transitions, preserves restoration attempts, passes 61 tests, physical C6 restart checks and deployment checks. Power state alone does not prove voltage.
    • Bridge #26: transient parent-hub disappearance/other ports appearing during C6 power-on remains an observation requiring diagnosis. restore_port_power=false means other ports returning on is not itself a proven restoration defect.
    • USB configuration-reset and cancelled-CDC-OUT rearming fixes in Zephyr CI: "tests / zephyr" job is failing on the BLE branches — cause not established #11 address repeated-import failures, with baseline/candidate controls linked to existing upstream #121843 and #122768. They do not resolve all remaining USB faults. Minimal fixtures and physical evidence.

    Two distinct unresolved USB workloads must remain separate:

    1. CP #42: direct Pico W closed-console MSC reads can wait until CDC is reopened. Recorded Python/SOF progress and later non-reproductions do not establish a priority, PM, HID or framing fix. Reproduce with the console open/closed/DTR-off controls and retain USBmon/host traces. Evidence.
    2. Pico 2 through S31: complete disk reads with 4 KiB requests pass in roughly 6.5 seconds; 64 KiB requests exhibit repeated 10/14-second delays. Matched captures localize the delay before reply arrival and, on the bridge, between HCD activation and retirement. The newer HCD capture places four complete replies' 10/14-second delays between activation and retirement; submit and callback delivery were below one millisecond. That diagnostic job separately failed on a 48-byte reply header advertising a missing 4 KiB payload. Its strict parse failure and separate restoration remain recorded. This does not distinguish device/host-controller causes or prove equivalence to zephyr-cp Pico W: closing CDC console can stall MSC reads until reopen #42. Comparison and timing limits.

    Mixed USB tests also directly captured HCD channel exhaustion with three leaves and three hubs. With the unused C6 off, both attachment orders pass with zero exhaustion messages. Exact live channel accounting and scheduling remain open. No failure was relabelled a success merely because a separate recovery passed.

    Other application/library findings and verification limits

    Application #38 reproduces non-atomic certificate/key promotion: failing the second rename can leave a new chain with an old key. Run python3 tools/repro_cert_install_failures.py .; evidence and fixture limits. A pair-recovery design is still needed; no physical power-loss guarantee is claimed. Full certificate-chain handling is a separate completed fix. Closed application #25 concerns oversized BLE writes, distinct from CP #25: twenty JS protocol groups (node webapp/tests/cert_sync.test.mjs) plus python3 tools/test_cert_ble.py cover bounded chunks, reassembly and disconnect cleanup. This is not fresh alpha.2 certificate installation or key/certificate-match qualification.

    The mpremote ENOENT conversion issue matches existing MicroPython #17752; fork draft PR #1 carries the candidate. Reproduce by copying a small file to a missing path with the stock CLI, compare direct open(path, 'wb'), then verify overwrite/readback/cleanup. The ESP32 V2 baseline fails and candidate passes. Matching MicroPython hardware and upstream review remain outstanding. JD79667 constructor logging/defaults have exact-source host controls and a retained minimal print-removal patch; it has not been deployed or submitted as a library PR. Actual panel timing and stray AttributeError require the absent rig. Library/tool evidence.

    Fresh bare-C6 checks cover five startup orderings, DHCP/HTTP, absent-card SPI unlock, exact 10,240-byte NUS transfer, disconnect/reconnect and bounded ESP-NOW with BLE. Seven of 100 sends fail; all 93 received echoes are exact. This does not qualify low negotiated MTU, sustained multi-sender traffic, shared display/SD wiring or real SCD41/RTC operation. Windows GATT-cache mechanism, battery events, real calibration/outage replay and several full-application scenarios remain explicitly unverified.

    For the original numbered bug document (these numbers are not GitHub issue IDs), the disposition is:

    Original reports	Disposition after investigation
    0/1/5/6: C6 AP, imports, radio ordering and memory	Reserve/frozen-library workarounds retained; five bare-C6 MCU-reset orderings and bounded DHCP/HTTP/radio checks pass. Controlled allocation failures and original display/sensor load remain unqualified. No new upstream defect or blanket closure is inferred.
    2: shared SPI lock corruption	Historical observation; no fresh corruption proof. Requires original shared wiring and lock-owner instrumentation.
    3: SD initialization leaves SPI locked	Normal absent-card failure unlocks on S3 and C6. Exceptional configure paths and shared display wiring remain unqualified.
    4: splash refresh/display errors	Explicit-root-group workaround retained; actual panel timer/BUSY/bus behavior unmeasured.
    7: low-memory BLE-mode GATT	Historical HTTP-import gating fix retained; constrained original display configuration remains unqualified.
    8/9: dropped notifications and post-disconnect writes	Current S3/C6 exact transfer and disconnect/reconnect controls pass. Low negotiated MTU, sustained load and broader races remain open.
    10: BLE-resident ESP-NOW TX memory	The bounded C6 BLE/AP/ESP-NOW test has seven sender failures in 100 attempts, without received corruption. This memory/load report is separate from the packet-publication fix. Sustained/multi-sender coverage remains open.
    11: S3 adapter disable/re-enable	Basic and post-NUS cycles pass; original application load remains unqualified and the board has since been removed.

    The old request in that document to file reports 1–4/#5 is not evidence that separate upstream issues were filed. No new filing or closure is claimed for unreproduced causes. The coverage ledger maps every original report and application TODO to evidence and remaining checks, including actual-drive relabel/interruption with concurrent HTTP/ESP-NOW, router-channel/autoconnect variants, outage replay, calibration and battery events. GitHub Pages/Adafruit IO and new rig assembly remain future product work. Missing hardware and source-only coverage are not passes or automatic closures.

    The new-issue tally is eight: CP #40/#42/#43, application #38, bridge #23/#26, controller #1 and Zephyr #12. Fix groups, upstream resolutions, workarounds and bench findings overlap; they must not be summed into a single issue total. The three newly closed trackers are Zephyr #5/#7 and HAL Pico #7; other existing upstream resolutions are listed above.
12. jakobi commented on Oct 24, 2026

    

    jakobi

    on Oct 24, 2026

    More actions

    @tyeth #1 "known limits" mention of georgerobotics cyw43-driver and its RP-license:

    I got curious about this driver and saw that Damien change the license of the driver to MIT in the meantime: https://github.com/georgerobotics/cyw43-driver/commits/main/LICENSE

    Given the date of change, I'd bet that you already know about this change, and forgot to add a footnote about the change in #1 :-).

    Thx for your work,
    P.

    ❤️React with ❤️1Reacted by Tyeth Gundry