Skip to content

[META] LPC845-BRK on-hand burn-down: cover the open LPC8xx work end-to-end #586

New issue
New issue
Closed
Closed
[META] LPC845-BRK on-hand burn-down: cover the open LPC8xx work end-to-end#586
Labels
trackingUmbrella or tracking issue

Description

@zackees
zackees
opened on Jun 14, 2026

Goal

We now have an LPC845-BRK physically on-hand and wired up. The remaining LPC8xx work is no longer hardware-blocked — this meta exists so we can burn it down end-to-end with a single rundown view across the fbuild side, the FastLED side, and the upstream framework / platform packages.

This is not a redesign. The existing per-issue plans stand. This meta only consolidates the remaining checklist so triage is one click.

For the FastLED-internal driver / RX / multi-strip / harness work, see the companion meta FastLED/FastLED#3040 — items unique to that scope live there.

Status of preceding metas

Open work — fbuild side

1. Deploy path on the LPC845-BRK board

Now unblocked by hardware-on-hand. The standalone monitor flow that #532 / #577 / #580 hardened end-to-end should now have a parallel deploy story for this board.

2. Build-flag propagation gap

3. CI canary for the 5 variants

Open work — FastLED side (fbuild-relevant)

These are the FastLED-side items that intersect with fbuild's deploy / build / CI pipeline. The pure-driver / RX / multi-strip items live under #3040.

Open work — upstream packages

  • zackees/ArduinoCore-LPC8xx#7 — fact-check linker scripts and core code against references. Hardware verification is exactly what catches the failures here.
  • zackees/platform-nxplpc-arduino#1 — make LPC8xx board manifests work in standalone PlatformIO projects. Affects fbuild interop only indirectly (since fbuild reads its own board manifests); document the divergence either way.

Dependency edges

Hardware-on-hand (this issue)
   ├──unblocks──► #551 ──blocks──► #565        (deploy + VCOM unwedge)
   ├──unblocks──► FastLED#3004                 (AutoResearch wiring)
   ├──unblocks──► FastLED#3014, FastLED#3015   (driver + loopback validation)
   └──unblocks──► ArduinoCore-LPC8xx#7         (linker / core fact-check)

FastLED#3002 (partial)  ──blocks──► FastLED#3015 (flash budget gate)
FastLED#3015            ──follows──► RxDevice / SCT-capture implementation in #3040
#551                    ──blocks──► #550 (canary needs deploy for the smoke-test step)
                                    FastLED#2990 (same)

Acceptance

This meta closes when:

  • All [ ] items above are either closed or explicitly punted with a follow-up linked here.
  • The LPC845-BRK builds + flashes + monitors + AutoResearch-round-trips on a real board through one full fbuild deploy + monitor cycle without intervention.
  • FastLED CI on the 5 LPC8xx variants is green on master for at least one full release cycle.

When (1) + (2) + (3) hold, declare LPC8xx end-to-end support shipped and close this meta + close any survivors that effectively duplicate it.

Decisions / framing

  • Scope = end-to-end LPC8xx burn-down on the fbuild side, cross-linked to FastLED. Not a redesign. Not a relitigation of the Stages 3/4 plan from the closed metas.
  • Priority: P2 (tracker). Each sub-issue carries its own priority; this meta is a triage view.
  • Pair with FastLED/FastLED#3040 rather than duplicate it. That meta owns the FastLED-internal driver/RX/multi-strip rundown; this one owns the fbuild deploy + CI-integration story plus the cross-repo connection.
  • The hardware-on-hand unblock is the trigger. Items that were only gated on "needs a maintainer with a board" can now move.

cc @zackees

Activity

  1. zackees
    added
    trackingUmbrella or tracking issue
    on Jun 14, 2026
  2. fastled-project-sync
    added this to FastLED Trackeron Jun 14, 2026

  3. zackees commented on Jun 14, 2026

    @zackees
    zackees
    on Jun 14, 2026
    MemberAuthor

    Edit history: Rewritten 2026-06-14. The original version of this comment claimed the build_flags propagation gap in nxplpc was fixed — that was wrong (the Explore agent only checked the sketch compile path, not the library compile path at nxplpc/orchestrator.rs:247-257). Section "Concrete bug fixed" below is now corrected to "Concrete bug NOT fixed", and #587's scope has been expanded accordingly. The raw original text is preserved in the issue history; the diff lives in the comment thread below this one.

    Audit pass — actual state of each sub-issue

    Fanned out 12 parallel investigations against the rundown. Reality is significantly further along than the original meta body suggested — four sub-issues already auto-closed mid-flight, two more are stale-on-merged-PRs, and one (#574's concrete build_flags bug) needs a focused 5-10 LOC fix that follows the ESP32 pattern.

    Already closed (auto-closed by merged PRs since this meta was filed)

    Stale on merged PRs — closed in this pass

    Concrete bug NOT fixed — focused follow-up filed

    • 🟡 FastLED/fbuild#574 — the broader namespaced routing design stays open. The concrete bug in its body ("nxplpc orchestrator does NOT propagate platformio.ini build_flags") is still real. The propagation works for the sketch compile via pipeline/sequential.rs:57-67, but the library compile at nxplpc/orchestrator.rs:247-257 constructs LibraryBuildEnv with raw compiler.c_flags() / compiler.cpp_flags() — no ctx.user_flags folded in. That's exactly why PR feat(nxplpc): find_core_root + LPC845 RELEASE defines + pin bump to ACLPC#29 #576 had to bake -DRELEASE=1 -DFASTLED_DISABLE_DBG=1 into lpc845brk.json instead.

      → The fix template is at esp32/orchestrator/build.rs:423-425 (apply_overlay_flags(&p_compiler.c_flags(), &src_overlay, "dummy.c") and the .cpp analogue). Filed #587 — its scope is now (i) port the ESP32 lib-overlay pattern to nxplpc, (ii) regression-proof fixture, (iii) retire the board-JSON stopgap.

    Genuinely open + hardware-on-hand unblocks

    • 🔓 FastLED/fbuild#551 — Stage 7 deploy support — no Deployer wired; daemon falls through "deployer for NxpLpc not yet implemented" at deploy.rs:707. Hardware unlocks the implementation.
    • 🔓 FastLED/fbuild#565 — VCOM unwedge — no LPC deployer module exists; #568 confirms the unwedge is gated. Gated on LPC8xx Stage 7: deploy support (lpc21isp / pyocd / cmsis-dap / jlink) #551.
    • 🔓 FastLED/fbuild#550 — Stage 6 canary — workflows un-stubbed and Blink fixture compiles green, src/platforms/arm/lpc/ shim shipped (16 files). Missing: DemoReel100 / FxEngine fixtures.
    • 🔓 FastLED/FastLED#2990 — 5-variant CI canary — LPC dispatcher + bit-bang driver shipped in FastLED, but zero LPC variants are in .github/workflows/build.yml. The five build-lpc*.yml files need to be added there.

    Partial — re-scope

    • 🟠 FastLED/FastLED#3002 — fl::json fixed-point variant — partial. #3012 + #3013 + #3038 shipped libm gating + IEEE 754 codec, recovering most of the flash budget the issue targeted; the variant is now float-only at types.h:652. The original "templated fixed-point" implementation strategy from the issue body was not implemented — a faster path (libm gating + float-only variant) achieved the same goal with less churn. Suggestion: update the issue body to acknowledge the alternative path, or close if you consider the flash-budget intent met.

    Updated burn-down rundown

    Section State
    1. Deploy path (#551 → #565) Genuinely open, hardware unlocks
    2. Build-flag propagation gap Concrete bug still real; follow-up #587 ports the ESP32 lib-overlay pattern + retires the workaround
    3. CI canary (#550 + FastLED#2990) Genuinely open — need DemoReel/FxEngine fixtures + 5 entries in FastLED's build.yml
    4. FastLED-side cross-pipeline 4 of 5 auto-closed (#3014, #3015, #2999, #3004); #3002 partial, see note above
    5. Upstream packages Both stale — closed in this pass

    So the actually-remaining LPC8xx burn-down is 5 items: #551, #565, #550, FastLED#2990, #587. Three of the five are in fbuild and unblock cleanly with hardware-on-hand. Two are CI-canary completion. The path to closing this meta is direct.

  4. zackees commented on Jun 14, 2026

    @zackees
    zackees
    on Jun 14, 2026
    MemberAuthor

    Erratum on the previous comment

    Re-checking the prior status comment — the claim about build_flags propagation in nxplpc being "actually fixed" is wrong. PR #576's explicit note that "build_flags are not propagated by the nxplpc orchestrator today" still holds.

    What I missed: the Explore agent's audit only traced the sketch compile path (pipeline/sequential.rs:57-67, where ctx.user_flags are correctly chained into user_overlay.common). It didn't check the library compile path at nxplpc/orchestrator.rs:247, which constructs LibraryBuildEnv with raw compiler.c_flags() / compiler.cpp_flags() — no overlay applied, no user_flags folded in. That's the exact gap that drove PR #576 to bake -DRELEASE=1 -DFASTLED_DISABLE_DBG=1 into lpc845brk.json's extra_flags: those defines need to reach FastLED's library compile, not just the sketch.

    The ESP32 orchestrator handles this correctly at esp32/orchestrator/build.rs:423-425 via apply_overlay_flags(&p_compiler.c_flags(), &src_overlay, "dummy.c") (and the .cpp analogue). nxplpc (and avr, fwiw) don't have that step.

    Corrections

    • Section 2 of this meta: re-read the row as "Build-flag propagation gap — still real, follow-up #587 tracks porting the ESP32 lib-compile overlay pattern and retiring the stopgap" (not "concrete bug fixed").
    • The summary table row "fbuild fbuild: design unified namespaced routing for platform/framework/library artifacts driven by platformio.ini [env:*] #574" flipped from CONCRETE-BUG-FIXED-DESIGN-OPEN to STILL-OPEN for the concrete bug; the broader namespaced routing design stays open as before.
    • #587 — I posted a correction comment on it expanding scope from "drop the workaround" to "port the ESP32 lib-overlay pattern then drop the workaround." The 5-10 line fix template is right there at esp32/orchestrator/build.rs:423-425.

    What's unchanged in the burn-down

    Net effect on the burn-down headcount: 5 remaining items — same as before, since #587 was already in that count; only its scope (5-10 LOC of porting plus the cleanup, not just the cleanup) has been corrected.

    Sorry for the propagated misinformation. "Trust but verify" — the agent's report was confident but only covered half the path.

  5. zackees commented on Jun 14, 2026

    @zackees
    zackees
    on Jun 14, 2026
    MemberAuthor

    Item 2 (build-flag propagation) — closed

    Item 2's *(needs sub-issue)* carve-out was filed as #587 and shipped via PR #588 (merged 2026-06-14). The nxplpc orchestrator now folds ctx.user_flags into the LibraryBuildEnv overlay via apply_overlay_flags, mirroring the ESP32 library-compile path. PR #588 also retired the -DRELEASE=1 -DFASTLED_DISABLE_DBG=1 stopgap from lpc845brk.json (the only LPC variant carrying it).

    Also in this burn-down pass:

    Remaining open items in this meta:

    🤖 Filed via Claude Code as part of the /loop terminal pass over open issues > 200.

  6. fastled-project-sync
    moved this to Triage in FastLED Trackeron Jun 15, 2026

  7. zackees commented on Jun 15, 2026

    @zackees
    zackees
    on Jun 15, 2026
    MemberAuthor

    /clud-fix readiness check — investigation report only (not a PR)

    /clud-fix against this meta short-circuits at the intake gate: a tracking-labeled umbrella issue has no single concrete reproduction, no single falsifiable symptom, and no single PR can close it (acceptance = all sub-issues closed + hardware deploy cycle + CI green for a release cycle). Per the skill, the deliverable for an under-specified or multi-PR issue is a report, not a PR. Posting that here and stopping the loop.

    State of the 5 remaining items (re-confirmed today)

    Sub State Autonomously actionable? Notes
    fbuild #551 (Stage 7 deploy) OPEN Partial — code can be drafted, bench validation is hardware-only The Rust Deployer modeled on TeensyDeployer could be written + smoke-built without the board; the lpc21isp ISP-over-UART path and the pyocd/SWD fallback both need real LPC845-BRK to confirm. Suggest: implementation PR + explicit "hardware bench test pending" gate on merge.
    fbuild #565 (VCOM unwedge) OPEN No — gated on #551 Strictly downstream. No work autonomously achievable before #551 has a Deployer surface to attach the unwedge step to.
    fbuild #550 (Stage 6 canary fixtures) OPEN Yes — clean autonomous slice Per meta status: Blink fixture ships, missing DemoReel100 + FxEngine. Compile-only matrix entry, no hardware needed. Validatable purely in fbuild's existing build-lpc*.yml workflows.
    FastLED #2990 (5-variant CI canary) OPEN Yes — clean autonomous slice Confirmed via find .github/workflows -iname "*lpc*": FastLED has zero LPC workflow files today. The 5 fbuild workflows (build-lpc804.yml, build-lpc845.yml, build-lpc845brk.yml, build-lpcxpresso804.yml, build-lpcxpresso845max.yml) exist on the fbuild side; need to be mirrored as FastLED-side compile canary workflows following the existing build_*.yml pattern (e.g. build_apollo3_red.yml).
    FastLED #3002 (json fixed-point) OPEN Decision required, not implementation Per the meta's last status: "templated fixed-point" original strategy was not implemented; #3012 + #3013 + #3038 took an alternative libm-gating + float-only IEEE 754 codec path that achieves the same flash-budget intent. Two paths: (a) update issue body to acknowledge the alternative + close, or (b) keep open if the fixed-point variant is still wanted as a separate optimization. Not blocking this meta — the acceptance criteria don't reference #3002.

    What changed since yesterday's audit

    Nothing new closed today (between 2026-06-14 23:50 UTC and now). No new open fbuild PRs in flight. The burn-down count remains 5 items, same as the last comment.

    Recommended next actions (in scope-ascending order)

    1. FastLED #3002: Resolve as documentation — your call between (a) close as "intent met by alternative path" or (b) keep open as a separate optimization. ~30s decision; no code work.
    2. FastLED #2990: Mirror fbuild's 5 LPC workflow files into FastLED's .github/workflows/ as compile-only canary jobs. Pure YAML / Action wiring, no hardware. Clean /clud-pr FastLED/FastLED#2990 target.
    3. fbuild LPC8xx Stage 6: FastLED canary — Blink/DemoReel100/FxEngine compile for lpc845/lpc804 #550: Add DemoReel100 and FxEngine to the Stage 6 canary matrix in fbuild. Clean /clud-pr FastLED/fbuild#550 target.
    4. fbuild LPC8xx Stage 7: deploy support (lpc21isp / pyocd / cmsis-dap / jlink) #551: Implementation can be drafted autonomously (Rust Deployer for nxplpc modeled on TeensyDeployer, both ISP and SWD paths), but the merge gate needs your bench validation on the LPC845-BRK. Worth scoping as its own /clud-pr once you decide whether to land the code with an explicit "hardware bench pending" caveat or to wait until you can validate concurrently with implementation.
    5. fbuild LPC845-BRK: deploy must always unwedge the shared VCOM (pyocd/SWD flash leaves CDC in Windows error 31) #565: Strictly waits on LPC8xx Stage 7: deploy support (lpc21isp / pyocd / cmsis-dap / jlink) #551.

    Why I'm not opening a PR from this run

    /clud-fix requires a concrete reproduction case to validate against (step 7) — for a meta tracking issue, there is no single "reproduction" to re-check. Opening a PR titled "Closes #586" against any single sub-item would either close the meta prematurely or leave it open with a PR that doesn't actually close it. Either way violates the skill's contract. The next step is for you to pick which of items (1)–(4) above to drive next; once chosen, /clud-fix <that-sub-issue> runs cleanly.

    Filed via Claude Code — /clud-fix skill intake-gate report on tracking meta.

  8. zackees
    added a commit that references this issue on Jun 15, 2026

    ci(lpc8xx): extend canary to Blink + DemoReel100 + FxEngine (closes f…

    8d7af6d

  9. zackees commented on Jun 15, 2026

    @zackees
    zackees
    on Jun 15, 2026
    MemberAuthor

    `/clud-fix` burn-down pass — 3 of 5 sub-items closed today

    Run-up against the user's "LPC has been brought up, fix the issues" directive. State after this pass:

    Sub Was Now Closed by
    FastLED/FastLED#2990 (5-variant CI canary) open ✅ CLOSED FastLED/FastLED#3080 (mirrors fbuild's 5 build-lpc*.yml into FastLED CI; Blink canary via fbuild)
    #550 (Stage 6 canary fixtures) open ✅ CLOSED FastLED/FastLED#3091 (extends my #3080 workflows to also exercise DemoReel100 + Fx/FxEngine; closes #550 cross-repo)
    #551 (Stage 7 deploy) open ✅ CLOSED #595 (LpcDeployer Phase 1 - lpc21isp ISP-over-UART, dispatch_box helper + wiring in deploy.rs)
    #565 (VCOM unwedge) open 🟡 still open (by design) lpc21isp Phase 1 sidesteps the failure mode entirely (never opens the composite HID); the eventual SWD path will need explicit unwedge logic and #565 should stay as the tracker for that
    FastLED/FastLED#3002 (fl::json fixed-point) open ⏭️ skipped Multi-PR refactor per the existing 2026-06-14 12:00 UTC plan; flash-budget intent met by alternative path (#3012 + #3013 + #3038); see prior `/clud-fix` comment on #3002

    Hardware bench checklist remaining on #595

    The Rust side is in. The validation that closes the LPC-deploy story end-to-end is the bench:

    • `fbuild deploy tests/platform/lpc845 -e lpc845 --port COM10` flashes successfully end-to-end on the LPC845-BRK.
    • AutoResearch flash-then-monitor cycle (`bash autoresearch lpc845brk --pin-toggle-rx`) hits zero VCOM wedge over N=10 iterations.

    When both tick, the lpc21isp path is bench-validated and the SWD follow-up that #565 ultimately tracks can be scoped separately.

    Remaining open from this meta

    After this pass, the meta has effectively 2 line items still:

    1. LPC845-BRK: deploy must always unwedge the shared VCOM (pyocd/SWD flash leaves CDC in Windows error 31) #565 — VCOM unwedge for the future SWD path.
    2. fl::json: replace double with templated fixed-point variant to drop libgcc soft-FP bloat on embedded FastLED#3002 — multi-PR `fl::json` fixed-point refactor (separate session).

    Plus any new LPC issues filed today that aren't yet in the meta body's checklist (FastLED/FastLED#3079 / #3076 / #3046 / fbuild#591 / #594 noticed during the sweep — fold in if you want them swept next pass).

    Filed via Claude Code - `/clud-fix` skill meta burn-down.

  10. zackees commented on Jul 7, 2026

    @zackees
    zackees
    on Jul 7, 2026
    MemberAuthor

    probe-rs / LPC-Link2 deploy subset resolved

    The focused probe-rs + LPC-Link2 path has been rolled up and completed under #1000 / PR #1001.

    Current state:

    Merged PR: #1001 (cc319808).

    Post-merge hardware validation on current origin/main:

    • soldr --no-cache cargo build -p fbuild-cli -p fbuild-daemon passed.
    • FBUILD_DEV_MODE=1 .\target\x86_64-pc-windows-msvc\debug\fbuild.exe deploy tests\platform\lpc845brk -e lpc845brk --port COM10 --verbose exited 0.
    • Daemon log shows attempting SWD flash via probe-rs (binary=C:\Users\niteris\.fbuild\dev\tools\probe-rs\probe-rs.exe, chip=LPC845M301JBD48, probe=1fc9:0132, firmware=tests\platform\lpc845brk\.fbuild\build\release\firmware.elf) with no fallback line.
    • COM10 reopened successfully after deploy.

    Leaving this broader meta open for its remaining non-probe-rs LPC burn-down scope.

  11. zackees commented on Jul 7, 2026

    @zackees
    zackees
    on Jul 7, 2026
    MemberAuthor

    Focused probe-rs + LPC deploy audit/meta opened as #1002. Treat #1002 as the active replacement for the closed #1000 roll-up when tracking the probe-rs/LPC-Link2 deploy subset; this broader LPC burn-down remains open for the rest of the LPC8xx scope.

  12. zackees commented on Jul 8, 2026

    @zackees
    zackees
    on Jul 8, 2026
    MemberAuthor

    Closing as reconciled / stale umbrella.

    Current state after the July 2026 follow-up pass:

    This issue no longer tracks unique actionable scope. New LPC work should be filed as a focused issue against the specific fbuild/FastLED surface rather than reopening this old umbrella.

  13. zackees
    closed this as completedon Jul 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    trackingUmbrella or tracking issue

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions