[META] LPC8xx compile + autoresearch + channels API end-to-end restoration — all blockers

[zackees]

Scope

bash compile lpc845brk --examples AutoResearch is broken on master against fbuild 2.3.14, and the editable-install escape hatch is also broken on Windows. This meta tracks every blocker that surfaced in a 2026-06-30 LPC bring-up attempt and the work needed to restore the LPC compile + autoresearch + channels-API path end to end.

Treat this as the punch list for getting LPC845-BRK back to a green bash autoresearch lpc845 and #3348's hardware bring-up acceptance criteria.

Blockers (in dependency order)

B1 — fbuild platform matcher rejects the hyphenated GitHub URL form

Status: PR open — FastLED/fbuild#900

fbuild::Platform::from_platform_str only substring-matches nxplpc. The FastLED LPC8xx fork (transferred from zackees/ on 2026-06-28 per ci/boards.py:1134) lives at github.com/FastLED/platform-nxp-lpc8xx.git — hyphenated. The exact platform = ... line written by boards.py:_NXPLPC_PLATFORM:

https://github.com/FastLED/platform-nxp-lpc8xx.git#12265f765aebd3893465d6d7ad76be66d89ba015

...fails the matcher and the build aborts immediately:

unsupported platform: https://github.com/FastLED/platform-nxp-lpc8xx.git#12265f76...
Compilation failed (fbuild) [2.2s]

Fix in PR: match both nxplpc and nxp-lpc substrings (one-line || extension in crates/fbuild-core/src/lib.rs + two new test cases covering the exact failing URL and the bare nxplpc registry name).

Closure: FastLED/fbuild#900 lands -> fbuild 2.3.15 ships to PyPI -> pyproject.toml pin bumps to fbuild==2.3.15.

B2 — framework-arduino-lpc8xx tarball checksum mismatch

Status: Needs upstream investigation.

After B1 is worked around locally (rewriting the generated platformio.ini to platform = nxplpc@<URL> so the current matcher catches it), the build progresses far enough to download the framework tarball and immediately fails:

build error: package error: checksum mismatch for ...
  framework-arduino-lpc8xx\858176fb46407fd4\0.2.0+g50d76e0_staging\
  50d76e0d63c2d2a2b365b29de47100d93c530c83.tar.gz:
  expected e6bbcc3392ae9da44c5c92268d7cd953770e0011fcf285561104633e36087428,
  got      e64f0cb81ab1673e05c2a63b7b4548c1373c9ba885413d2a2351bbfae160fbec

Deleting the cached tarball and forcing a re-download produces the same got e64f0c.... The expected e6bbcc33... is whatever fbuild 2.3.14 recorded at packaging time; the actual tarball GitHub serves today is e64f0cb8....

Suspected cause: the 2026-06-28 org transfer (zackees/ -> FastLED/) caused GitHub to regenerate tarball metadata (parent-dir name in the archive flips owner), which changes the SHA256 even though git content is unchanged. fbuild's pinned checksum was recorded against the pre-transfer tarball and no longer matches.

Required fix: Re-record the checksum against the post-transfer tarball, in whatever fbuild manifest or platform-repo manifest the SHA256 is sourced from. (Probably ships alongside the fbuild 2.3.15 release that includes B1, or in the platform-nxp-lpc8xx repo's manifest at SHA 12265f76.)

B3 — Editable pip install -e ~/dev/fbuild fails on Windows due to windows-gnu toolchain selection

Status: Out of scope for FastLED but blocks the obvious B1/B2 workaround.

The natural workaround for B1+B2 is "use the local fbuild 2.3.15 dev checkout via editable install." That fails with:

ERROR: cargo build succeeded but no `_native` cdylib was found.

setup.py runs soldr cargo build -p fbuild-python --features extension-module and expects target/release/_native.dll. Direct repro with rustup-stable cargo reveals the real failure soldr swallows:

error: linking with `rust-lld.exe` failed: exit code: 1
  = note: lld: error: unable to find library -lcfgmgr32

rust-toolchain.toml pins channel = "1.94.1" without specifying host. On this Windows machine rustup defaults to the windows-gnu variant; rust-lld runs in -flavor gnu, links against <sysroot>\lib\rustlib\x86_64-pc-windows-gnu\lib\self-contained\, and that self-contained dir does not include the cfgmgr32 import lib that pyo3-tokio drags in via windows-sys. The MSVC variant's std libs aren't fully bootstrapped on this machine either (error[E0463]: can't find crate for std for x86_64-pc-windows-msvc), so a per-invocation --target x86_64-pc-windows-msvc doesn't rescue it.

Required fix path: Either pin the host triple in fbuild's rust-toolchain.toml (channel = "1.94.1-x86_64-pc-windows-msvc" for Windows), document the MSVC target setup, or surface soldr's swallowed link error so setup.py doesn't claim "no cdylib produced" when the real failure is a missing system import lib.

Cross-repo, filed against fbuild as part of B1's PR description context; this can become its own fbuild issue if the user wants tracking.

B4 — fl::DefaultBus<ClocklessChipset> has no LPC specialization

Status: Code-only investigation done; landing blocked on B1+B2 (no compile-validation path).

src/fl/channels/bus.h declares DefaultBus<> specializations for STUB/WASM, ESP32 (RMT/FLEX_IO), and Teensy 4.x (FLEX_IO). LPC has none. New sketches that reach the channels-API selector instead of the legacy template path will fall through with no default. The right specialization for LPC8xx is Bus::BIT_BANG — the existing src/platforms/arm/lpc/clockless_arm_lpc.h uses the shared M0 cycle-counted C++ implementation (per FASTLED_M0_USE_C_IMPLEMENTATION set in led_sysdefs_arm_lpc.h:35), which is exactly what BIT_BANG already names.

Compile validation requires the build path to work. Will land after B1+B2.

Already-resolved adjacent timing/clock work (context, not action items)

These were specifically mentioned in the bring-up request and have already shipped:

• F_CPU 30 MHz -> 24 MHz correction in src/platforms/arm/lpc/led_sysdefs_arm_lpc.h:39-49. LPC845 FRO direct path is 24 MHz; the previous 30 MHz default produced ~25% cycle-count drift on bit-bang and SCT+DMA clockless drivers. Both the Arduino core's boards.txt and fbuild's lpc845brk.json declare f_cpu=24000000L; the header now matches.
• HardFault_Handler override wired through zackees/ArduinoCore-LPC8xx#31 (no longer aliased to the silent infinite-loop default) — referenced in [BLOCKER] LPC845-BRK AutoResearch bring-up echo returns empty RX (suspected HardFault) — blocks #3102 #3300 comment thread.
• Serial.println silent on LPC845-BRK — fixed in [BUG-LPC] Serial.println / fl::println silent on LPC845-BRK -- Serial.print works fine (blocks #3300) #3313 / fix(platforms/lpc): work around Serial.println silent-drop on LPC8xx (closes #3313) #3314 (not the bring-up echo blocker though; see [BLOCKER] LPC845-BRK AutoResearch bring-up echo returns empty RX (suspected HardFault) — blocks #3102 #3300).
• HardFault regressions — LPC845-BRK: AutoResearch firmware HardFaults during early init (regression since b468ed7) #3200, lpc845: pinToggleRx + ws2812SctTest handlers stack-overflow at runtime (8 KB stack buffer on 16 KB SRAM) #3125 fixed.

Active downstream / linked work

• [BLOCKER] LPC845-BRK AutoResearch bring-up echo returns empty RX (suspected HardFault) — blocks #3102 #3300 — [BLOCKER] AutoResearch echo returns empty RX. The current hardware-side bring-up gate. Unblocked by B1+B2 on the toolchain side; still needs USART0 clock / SWM / setup() crash hypothesis testing on hardware.
• META: LPC845-BRK AutoResearch bring-up and validation #3348 — META coordinator for LPC845-BRK AutoResearch bring-up (this issue feeds B1-B4 into that punch list).
• Rename LPC board target lpc845brk to lpc845 #3220 — Rename board target lpc845brk -> lpc845. Lands after B1+B2 unblock CI compile.
• [Type-Erasure] chipsets: ClocklessControllerRuntime -- runtime-timing concrete class (#3244 Tier 2F) #3248 — ClocklessControllerRuntime (LPC explicitly stays on template path; B4 is the right LPC routing for the channels-API consumer).

Acceptance criteria for closing this meta

• fbuild PR fix(core): match nxp-lpc (hyphenated GitHub form) in platform parser fbuild#900 is merged, fbuild 2.3.15 is on PyPI, and pyproject.toml is bumped (closes B1).
• bash compile lpc845brk --examples AutoResearch completes without a checksum error against fbuild 2.3.15 on a fresh cache (closes B2).
• Editable uv pip install -e ~/dev/fbuild succeeds on Windows on a clean repro machine, OR an MSVC-host pin lands in fbuild's rust-toolchain.toml with a Windows note in RELEASING.md (closes B3).
• fl::DefaultBus<ClocklessChipset> resolves to Bus::BIT_BANG on LPC8xx and a compile-only smoke for examples/Blink on lpc845brk builds green (closes B4).
• [BLOCKER] LPC845-BRK AutoResearch bring-up echo returns empty RX (suspected HardFault) — blocks #3102 #3300 echo/RX path is green on hardware (closes the bring-up gate, which is the underlying reason this meta exists).

Close policy

Close when all five acceptance boxes flip, OR when a remaining box is explicitly deferred with rationale and re-tracked under a narrower successor issue. Do not close while any of B1-B4 is still load-bearing for #3300 / #3348.

---

Repro evidence and full investigation log was captured in the 2026-06-30 LPC bring-up Claude session that filed FastLED/fbuild#900.