nxplpc: LpcDeployer feeds -hex to a .bin firmware and passes CMSIS-DAP speed=1000 as the lpc21isp baud #927

Two code-side blockers that surface the moment you actually run fbuild deploy tests/platform/lpc845brk -e lpc845brk --port COM10 against a physically-attached LPC845-BRK. Both are in the current LpcDeployer (crates/fbuild-deploy/src/lpc.rs) — the lpc21isp binary path resolver from #921 unblocked getting here.

1. -hex flag hardcoded, but the nxplpc orchestrator emits .bin

LpcDeployer::deploy() at crates/fbuild-deploy/src/lpc.rs unconditionally builds:

lpc21isp -control -wipe -hex <firmware_path> <port> <baud> <xtal_kHz>

But the nxplpc orchestrator lands the firmware at .fbuild/build/release/firmware.bin (raw binary, 1872 bytes for the empty test sketch), NOT firmware.hex. lpc21isp with -hex expects Intel HEX; when handed a raw ELF-extracted .bin it aborts with exit 1 before touching the serial port.

Repro on a physically-attached board (COM10 was open, board wasn't in ISP mode but the format probe happens first):

$ target/…/fbuild.exe deploy tests/platform/lpc845brk -e lpc845brk --port COM10
lpc21isp failed (exit code 1)

Fix candidates:

• A. Auto-detect the firmware extension: pass -hex only when the path ends in .hex; otherwise omit it and let lpc21isp treat the file as raw binary (its documented behavior without -hex).
• B. Have the nxplpc orchestrator ALSO emit firmware.hex (via objcopy -O ihex firmware.elf firmware.hex) and route firmware_path accordingly.

Preference: A. Cheaper — no orchestrator change, no extra artifact, and it makes the deployer robust against future orchestrator variants (e.g. if a board is added that ships as .hex from vendor tooling, both paths just work).

2. LpcDeployer::from_board_config uses board.upload_speed as the serial baud, but lpc845brk.json sets that field to 1000 (a CMSIS-DAP throughput knob)

crates/fbuild-config/assets/boards/json/lpc845brk.json currently carries:

"upload": {
  "protocol": "cmsis-dap",
  "protocols": ["cmsis-dap", "isp"],
  "speed": 1000,
  "tool": "openocd"
}

That speed: 1000 is openocd's adapter-clock throughput (kHz), not a serial baud. But LpcDeployer::from_board_config blindly reads board.upload_speed and hands it to lpc21isp as <baud> in argv. Result: the child process is invoked as … COM10 1000 12000, which lpc21isp autobauds against but never succeeds on any real LPC845-BRK ISP handshake.

Contrast with lpc845.json (family base) which correctly has protocol: "lpc21isp" and speed: 115200 — but the family default doesn't override the board-specific mis-configured value.

Fix candidates:

• A. Guard the baud read in LpcDeployer::from_board_config: if the family default is 115200 and board.upload_speed is a value that is definitely-not-a-baud (< 4800), ignore it and use the family default. Cheap and defensive.
• B. Fix lpc845brk.json to override only the CMSIS-DAP protocol/throughput and keep the ISP baud at 115200 via a distinct field (e.g. upload.isp_speed = 115200). Requires a schema addition.
• C. Split upload.speed semantically: when protocol == \"cmsis-dap\" treat speed as adapter kHz, when protocol == \"lpc21isp\" treat speed as baud. That's the honest fix but requires threading protocol context into the deployer.

Preference: A + C combined. Ship A now as the safety net (LpcDeployer refuses to use a sub-4800 value as baud), file C as a follow-up refactor tracked separately.

Reproduction summary

Environment: Windows 10, LPC845-BRK attached at COM10 (VID:PID 1FC9:0132 — the LPC-Link2 CMSIS-DAP debug interface. The CDC sibling is what lpc21isp is supposed to open).

$ target/x86_64-pc-windows-msvc/release/fbuild.exe deploy \
    tests/platform/lpc845brk -e lpc845brk --port COM10
… (build succeeds, produces .fbuild/build/release/firmware.bin)
lpc21isp failed (exit code 1)

lpc21isp was installed at ~/.fbuild/prod/tools/lpc21isp.exe (compiled from SF lpc21isp_197.zip source via MinGW-gcc) so the #921 path resolver did resolve it.

Acceptance

• fbuild deploy tests/platform/lpc845brk -e lpc845brk --port COM10 no longer fails on -hex .bin format-parse or on speed=1000 autobaud.
• Board still needs physical ISP entry (SW3+SW4) for the actual flash to complete — that hardware gesture is out of scope here.
• Regression test in crates/fbuild-deploy/src/lpc.rs covers both fixes: a test that a .bin path drops -hex, and a test that upload_speed < 4800 triggers the safety-net fallback to params.default_baud.

Related

• fbuild deploy: own nxplpc/LPC8xx flash end-to-end (FastLED is removing its direct pyocd path) #921 — LpcDeployer path resolver (merged / in-flight PR feat(deploy): lpc21isp path resolver + baud/hex safety nets (#921, #927) #923 supplies the binary discovery)
• LPC845-BRK: deploy must always unwedge the shared VCOM (pyocd/SWD flash leaves CDC in Windows error 31) #565 — VCOM unwedge acceptance (subsumed by the lpc21isp path)