Repository navigation
Tracking: Pico W / Pico 2 W Bluetooth + Soft_AP DHCP + SSL/TLS HTTP Server via the CYW43439 shared gSPI bus #15
Description
Activity
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.
Body updated with the CI evidence now that both boards build green in CI.
- New CI verification section:
ci/pico2w-ble-assetsrebased to94bfd47b5f(0 commits behindmain, was 229) so the override branch exercises the currentboards/<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 / zephyrjob that #11 is about, so #11 will be re-evidenced from #5's result rather than the pre-rebase run.🤖 Generated with Claude Code
- New CI verification section:
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 BPico W …pico_w…94bfd47.uf2· 2,363,392 B.elf· 22,310,200 BBuilt from
ci/pico2w-ble-assets@94bfd47b5f. Both UF2s load from0x10000000with the correct family IDs (0xe48bff56RP2040,0xe48bff57RP2350) — independent confirmation.boot2is linked, versus the0x00000100start 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 withgh release delete v-zephyr-cp-ble-ci-20260909whenever it has served its purpose.🤖 Generated with Claude Code
Edit: the release tag was renamed to
v-zephyr-cp-ble-ci-20260909and the links above updated. A tag not starting withvis picked up bypy/version.py(git describe --first-parent --match "[!v]*"), which broke every pristine build and both CI asset builds onci/pico2w-ble-assetswith "Cannot determine version". Thev-prefix makes it invisible to that matcher.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-D754was 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)toMemoryError212,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), andport_heap_init()skips its TLSF pool when picolibc'sARENA_SIZE=-1arena covers the same region, routing allocations through Zephyrmalloc. 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 butap_activestaysFalse;busio.I2C(scl, sda)→NotImplementedError('Use device tree to define I2C devices');board.I2C0/I2C1/SPI/UARTexist as callables.Two corrections to what this issue and the port doc imply:
CONFIG_BT_MAX_CONN=1is 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.start_apbeing a stub is not a missing driver:airoc_mgmt_ap_enable/ap_disableexist indrivers/wifi/infineon/airoc_wifi.cand are registered inwifi_mgmt_ops. zephyr-cp just never issuesNET_REQUEST_WIFI_AP_ENABLE. Zephyr also shipsdhcpv4_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
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-timeout3c6020d4d8the #18 "stall" is Zephyr ignoring scan_param.timeouton the legacy path; deadline enforced from the main thread; console RX wakes the main thread#21 zephyr-cp-pico2w-sockets-tls04a55c99daTCP had never been enabled on these boards (EPROTOTYPE → "Out of sockets"); fd table 16; socketpool finaliser fault fix ( zsock_shutdown(0)→ jump intocdc_acm_1), errno reporting, accept inherits timeout;sslserver contexts stop demanding a client cert (shared-module, all ports); PEM parsing; p256-m off (mbedTLS sizes the TLS 1.2 premaster from a dummyECP_MAX_BITS 1→PSA_ERROR_BUFFER_TOO_SMALLon every ECDHE)#22 zephyr-cp-pico2w-softap8ea8f3f75cstart_ap/stop_ap/ap_active/stations_ap/ipv4_address_ap/DHCPv4 server with RFC 8910 option 114#23 zephyr-cp-frozen-modulesfb700f76bcFROZEN_MPY_DIRSincircuitpython.toml; Pico W freezesadafruit_bleModule forks
Branch Contents tyeth/zephyr airoc-softap-fixes(3943b1cd7, on top ofcyw43-shared-bus-ble)AIROC ap_enablechanspec 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 dormanttyeth/hal_rpi_pico cybt-ring-index-failure-paths(cc2ea478, merged intointegration-pico2w-ble)cybt_hci_write_buf/cybt_hci_readhonourcybt_get_bt_buf_index()failure — a garbagehost2bt_in_valmadememcpyread off the end of SRAM (bus fault, BFAR 0x20082000, threadbt_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_aptracks join/leave/rejoin; AP survivesstop_ap/start_apand a soft reboot with a station attached; HTTPS served from a PEM RSA-2048 cert over the AP, C6 client receivesHTTP/1.0 200 OKin 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 HCIHardware error, hardware code: 0events (~74 at 7 ms intervals) andcybt_get_bt_buf_index: out-of-range indexretries, andbt_enable()did not complete within 8 s — withCONFIG_BT_ASSERT=ythat ends inController unresponsive, command opcode 0x1009 timeoutand 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 aftercybt_fw_download/cybt_wait_bt_readyreading a ring whose indices are not yet valid. Not fixed here.Open items
make DEBUG=1is broken by shell;in-Dzephyr-cp_EXTRA_CONF_FILE=a.conf;b.conf(runsb.confas a command, "Permission denied"); the debug fragment is silently dropped.mpversion.his stale in an incremental build dir (zephyr-cp: boot_out.txt reports a stale version on incremental builds #10) — the board reports-51while running-52code.ci/pico2w-ble-assetsneeds itszephyrrevision moved toairoc-softap-fixesand rebasing onto zephyr-cp: freeze .mpy modules named in circuitpython.toml #23 to CI-verify this stack.
🤖 Generated with Claude Code
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 theKeyboardInterruptsimply 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_apwas "a hook-up job, not a driver port" becauseairoc_mgmt_ap_enableexists. The driver was in fact broken: it composed band/bandwidth bits into a chanspec that WHD'swhd_wifi_init_ap()re-wraps withCH20MHZ_CHSPEC(), turning channel 1 into0xd001(5 GHz) and failing every AP start withWLAN_BADCHAN. Fixed on the zephyr fork, not in CircuitPython. - I said "
ssl/socketpoolare already enabled" as though TLS would work.CONFIG_NET_TCPhad never been enabled for these boards, so noSOCK_STREAMsocket had ever succeeded — it failed withEPROTOTYPE, misreported as "Out of sockets". Three further defects had to be fixed before a handshake completed.
🤖 Generated with Claude Code
- I said
- 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 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_ASSERThalts 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.cfgwith 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
OSErrorinstead 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 serialwhen more than one CMSIS-DAP probe is present.🤖 Generated with Claude Code
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 thatmainand 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(unquotedEXTRA_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=4upstream prj.confnow setsCONFIG_BT_MAX_CONN=5for every boarddropped (4 would have lowered it). The Pico W sets 2 in its own board.confto give the heap back (#14,b610e43da2)zephyrproject-rtos/zephyr
fork issue defect our fix tyeth/zephyr#3 settings_nvs:sector_cnt==0withrc==0treated as success, then an uninitialisedhw_flash_sectoris read (sawfs_size=537016640)avoided by sizing the partition correctly (now 8K at 0x17e000on top of upstream's Adaboot layout, #4/#14)tyeth/zephyr#5 udc_rpi_pico: unalignedmemcpyto/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 busylogged as an error during normal CDC transmission (1400+ line bursts)none — cosmetic unless LOG_MODE_IMMEDIATEtyeth/zephyr#8 airoc:ap_enablebuilds a chanspec thatwhd_wifi_init_ap()re-wraps, so every softAP start failsWLAN_BADCHAN; plus a station DEAUTH taking the AP interface dormantairoc-softap-fixestyeth/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_BITSwhen p256-m serves P-256 →PSA_ERROR_BUFFER_TOO_SMALL#21 The
tyeth/zephyroverride branches (cyw43-shared-bus-ble,airoc-softap-fixes) are still based on62e7a3764b, 9 commits behind upstream CircuitPython's Zephyr pin70f1a63cc8. 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_CTRLreads come from a software cache, making the corruption check incybt_toggle_bt_intr()vacuousnone — 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 ittyeth/hal_rpi_pico#5 tyeth/hal_rpi_pico#7 hardware_flash:static inlinehelpers can be emitted to flash and called with XIP disabled → silent hang, unrecoverable over SWDtyeth/hal_rpi_pico#2 The
hal_rpi_picoandhal_infineonoverride 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-sideSSLContextwrongly requires a client certificate (-0x7480), unlike CPython. Affects all portsba0232c35aon #21's branch (wascbcfeec077)still present: SSLSocket.csetsMBEDTLS_SSL_VERIFY_REQUIREDfor a server side too#27 ports/zephyr-cp_bleio: afterbt_enable()fails inbt_hci_open(), nothing clearsBT_DEV_ENABLE, so the retry takes-EALREADYas success —settings_load()then runs on an uninitialised host, yielding a random static BD_ADDR and, when the GATT db hash differs, ak_workNULL handler → UsageFault → kernel halt (USB drops)none yet — fix proposed in the issue (clear BT_DEV_ENABLEon failure; accept-EALREADYonly whenbt_is_ready(); never fall back to a random identity)still present: bleio_adapter_ensure_stack_ready()accepts-EALREADY, then callssettings_load()#28 py/version.pytests"CP_VERSION" in os.environ(presence, not truth), so an emptyCP_VERSIONexported by.github/actions/mpy_crossaborts "Set up mpy-cross" with Cannot determine version. Bites any board with frozen modules whose caller passes an emptycp-version393be068abonci/pico2w-ble-assets(was7ba84d8936) — 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+sslunusable 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_bleiochanges its service set between boots (e.g. theCIRCUITPY{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 .hcdis not a usable patchram alternative)tyeth/hal_infineon#1 espressif/esp-idf
fork issue defect our fix tyeth/esp-idf#1 lwip/dhcpserver.cfails to build withDHCPS_DEBUG=1(%xvsu32_t)submitted upstream — espressif/esp-idf#19074 (still open, tracked as IDFGH-18269) Not upstream — ours to keep
#8 (
BT_EXT_ADVdefault), #9 (start_scan(extended=)ignored), #10 (staleboot_out.txt), #12 (CI-onlywest.ymloverride), #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 byffd62e1c59), #11 (tests / zephyrgreen 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
https://github.com/tyeth/circuitpython/tree/zephyr-cp-rtt-console for RTT mode, both Pico+Pico2w
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_plannedby the stale bot, not on merit).State as of 2026-09-09 (rebased onto
main121489fe70)mainmoved between the first PRs and now, and two things it did changed this stack:boards/<board>.overlay|conftoboards/<vendor>/<board>/board.overlay|conf(d0f27bfc97). All three branches were rebased and their board-file changes relocated.mainfixed the RP2040ranges;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 pinnednvm/circuitpyto matchports/raspberrypivia a newcheck_partitions.pyparity 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 growstorageto 8K at0x17e000out of the code partition and leavecircuitpyalone — CIRCUITPY is no longer reformatted by these branches. That placement is build-tested; the hardware runs used the earlier0x181000layout.Pull requests
This repo — stack:
main→ #5 → #4 → #14main5f0ea1254abb410ab1648d2023c6b5main74e414d323#13mainranges;fix landed upstream asffd62e1c59Module forks
hal_rpi_picobranch builds working firmware — both its commits must be combined (currentlyintegration-pico2w-ble, see #12).Build (post-rebase heads, local zephyr tree with the driver)
CONFIG_BT/CONFIG_BT_CYW43_SHARED_BUScheck_partitions.pyraspberry_pi_pico2_wraspberry_pi_pico_wCI 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 oneCI-only commit overriding
zephyr/hal_rpi_pico/hal_infineoninzephyr-config/west.ymlto thefork 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 thereforeexercises the current
boards/<vendor>/<board>/layout.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.boot2is linked, i.e. the #6 failure modetested 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.
--refand-f branch=—--refonlyselects the workflow file, while the checkout uses the
branchinput (defaultmain), so a--ref-only dispatch silently buildsmainand yields an artifact with no Bluetooth in it.Issues
ranges(fixed upstream,ffd62e1c59)BT_EXT_ADVdefaults on port-wide, asserting a capability not all controllers havestart_scan(extended=)silently ignoredboot_out.txtstale version on incremental buildstests / zephyrCI job red — cause not established; being re-evidenced post-rebase on #5's runwest.ymloverride must not merge; depends on an unreviewed branchpull_requestrun). Path now verified green via the override branch — see abovedebug.conf-only (verified on hardware; +unexplained post-scan stall)make DEBUG=1was broken by an unquotedEXTRA_CONF_FILE(validated)settings_nvsreads an uninitialized struct when a partition holds zero sectorsSeven defects were fixed to get here — only one was mine
memcpyinto USB DPRAM (M33 widens transfers; M0+ didn't)UDC_RPI_PICO_STACK_SIZE512 B under immediate loggingstorage_partition2 KB & misaligned → NVS-EDOM(now: 4 KB upstream → NVS-EINVAL, still needs two sectors)-EDEADLKflash_enable_writeemitted to XIP, called with XIP off → silent core hangcyw43_btbus_init(NULL)— cybt NULL-checks the handle as a sentinelBT_EXT_ADVon a controller lacking extended advertisingKnown limits
hal_infineon.hcdis not an alternative — it is the sameCYW4343A2firmware family at an older patch level (...0031vs pico-sdk's...0065) and built for UART transport, not the shared bus.cyw43-driversubmodule supplies the controller patchram and is underLICENSE.RP, which permits use only alongside Raspberry Pi silicon. Fine for these boards; a blocker for upstreaming to Zephyr proper.debug.confbuild is unsafe:LOG_MODE_IMMEDIATEformats 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).