v2.3.7

AI Efficiency Optimizations

1. Tool list −20 % — the tools/list every turn carries shrank from 33.2 to 26.7 kB (single-window surface); per-call timeoutMs notes collapsed to one line, rationale moved to the skill; a 30 kB budget and 700-char/description cap are asserted in the transport test.
2. serial.enabled setting — off drops the ten serial_* tools from the list entirely.
3. get_debug_instructions by topic — ~2 kB overview + one section on request instead of one 21 kB block.
4. Compact motion state — step/continue/pause/wait_for_stop return location, frame ids, top 5 frames and the breakpoint list only when it changed; full snapshot only at session start.
5. Capped listings — variables: 40 per scope, 200 chars per value (uncapped with variableNames); call stack: 20 frames, workspace-relative paths; threads: 32; read_memory defaults to hex.
6. Lighter recovery — after a motion timeout, PC and LR are read instead of all 23 core registers.
7. diagnose_fault — one call replaces the ~6-call HardFault loop (fault registers as one 24-byte read, stacked frame, top frames, address resolution, ranked hypotheses with the next call).
8. lookup_peripheral / lookup_register — SVD answers with no session and no target access; unknown names get suggestions instead of the full name list.
9. cmsis_action target check/switch — every result names the target it ran on and target switches/verifies it, removing the wrong-target build → confused-investigation round trips.
10. Measurement built in — per-call telemetry (bytes in/out, ms, outcome), the cmsis-developer-assistant://stats resource, the get_session_status trailer and optional JSONL export; the eval-scenario runner scores an agent's run against tool-call, turn and time budgets.

[2.3.7] - 2026-08-25

Added

• cmsis_action checks and switches the target — the tool used to act on whatever target-type the CMSIS Solution panel happened to have selected, and its result never said which; on a board + FVP or HE/HP solution a build or flash could go to the wrong context unnoticed. Every result now names the target it ran on (✅ CMSIS 'build' succeeded on HP@debug …), get_device_info reports the panel's CMSIS target:, and the new optional target input (MPS3 or HP@debug, the csolution's own names) selects one: a differing target is switched — the selection is written to .vscode/cmsis.json and the solution re-activated, the mechanism the extension (1.70) itself uses since it exposes no command for it — and verified through cmsis-csolution.getActiveTargetSet before anything runs. An undeclared target is refused with the declared list, an unverifiable switch with what was written and what the extension still reports, and a switch under a live debug session with a pointer to stop_debugging. The build topic and the cmsis-debug-live skill say when to pass target; the transport test drives the refusal, switch and no-op paths against a stubbed extension.
• Agent evaluation scenarios — npm run eval:scenario -- <id> runs a real Copilot CLI session against a planted bug and reports what it cost: tool calls by name with argument and result bytes, reasoning turns, wall time, the server's per-tool byte totals (from the cmsis-developer-assistant://stats resource, diffed around the run), and a verdict from the final answer against the expected root cause plus tool-call, turn and time budgets; infrastructure failures are reported as such, not as agent failures. Ships the BSP Blinky example for the Corstone-300 FVP as the fixture (test/eval/fixtures/corstone-blinky, with the FVP shim for Docker on macOS) and five deterministic scenarios (divide by zero, undefined instruction through a corrupted function pointer, MSPLIM stack overflow, unaligned access, an LED off-by-one with no fault). Opt-in only — it needs an authenticated Copilot CLI, a VS Code window on the work directory and an FVP or board; the pure logic (scenario validation, event aggregation, verdict, mcp-config edit) is unit-tested. scripts/test-skill-trigger.ts shares the Copilot CLI helpers.
• diagnose_fault — one call replaces the six-call HardFault loop: the decoded fault registers (read as one 24-byte SCS block), the stacked exception frame located through EXC_RETURN (PSP or MSP, basic or FP-extended) with the PC of the faulting instruction and its caller, the top frames, the faulting address resolved against the SVD or the Cortex-M system map (an unclocked I2C1.CR1, a null pointer plus offset, SRAM), and up to three ranked hypotheses each with the next tool call — unclocked peripheral, null pointer, wild pointer, imprecise write, stack overflow (with MSPLIM/PSPLIM when the core has them), corrupted function pointer, missing Thumb bit, unaligned access, divide by zero, FPU off, bad VTOR. Every section after the fault registers degrades to a note instead of failing the call; with no fault flag set it returns a short stop context. get_fault_info now also names STKOF (Armv8-M stack limit) and DEBUGEVT, and its text is otherwise unchanged. Four long tool descriptions were shortened to keep the tool list within its byte budget.

[2.3.6] - 2026-08-24

Added

• lookup_peripheral and lookup_register — answer SVD questions without a debug session and without touching the target: the peripheral list, a peripheral's register map (offsets, absolute addresses, access), which peripheral and register sit at an address (turn a BFAR into I2C1.CR1), and one register's bit fields with their enumerated values (which bit is the clock enable). The SVD is resolved from an explicit svdFile, the active session, out/**/*.cbuild-run.yml (pname picks the core) or a single workspace .svd, and the failure text lists what was tried. Unknown names get suggestions instead of the full name list — read_peripheral_register now does the same and points at lookup_peripheral. The parser reads addressBlocks, enumeratedValues and dim register arrays, and no longer borrows a field's access for its register.
• cmsis-developer-assistant.serial.enabled (default on) — off leaves the ten serial_* tools out of the MCP tool list, which every agent turn carries. Fixed per server instance (window reload), so the tool list a client sees never changes between turns.

Changed

• Smaller tool results. Step, continue, pause and wait_for_stop now return a compact state: the location and frame ids, the top 5 frames with the rest counted, and the breakpoint list only when it changed since the last snapshot (a count otherwise) — the full snapshot still comes back when a session starts. read_memory defaults to hex (ascii / both on request). get_call_stack prints workspace-relative paths and collapses frames beyond 20 unless levels is given; get_threads lists up to 32 tasks. Variable listings without variableNames are capped at 40 variables per scope and 200 characters per value, with a footer saying how many were left out and how to widen; with variableNames nothing is capped. The recovery section after a motion timeout reads PC and LR instead of all 23 core registers. Tool descriptions state the caps.
• Smaller tool list. The serialized tools/list every client receives at initialize — and re-sends to the model on every turn — shrank by a fifth (33.2 → 26.7 kB for the single-window surface): the per-call timeoutMs note is one short line per tool with the rationale once in the server instructions, and the start_debugging, cmsis_action, reset, add_breakpoint, add_logpoint, flash and get_debug_instructions descriptions carry the trigger and the one caveat an agent needs at call time; the reasoning moved to the cmsis-debug-live skill and the get_debug_instructions topics (build for the result line and long builds, breakpoints, inspection for reset methods). The transport test now asserts a byte budget for the tool list and a 700-character cap per description.
• get_debug_instructions takes a topic — the guide for harnesses that do not load skills (GitHub Copilot Chat) no longer arrives as one 21 KB block. Without topic the tool returns a ~2 KB overview (the critical steps, the debugger-first rule) plus the list of topics; session, build, breakpoints, inspection, faults and troubleshooting return one section each. The guide itself was restructured around those topics (marker comments a Markdown reader never sees), gained a faults section (EXC_RETURN, the stacked frame, resolving BFAR, the usual cause per flag) and a build section (cmsis_action result line, long builds, flash, attach), and its inherited root-cause examples about getUserById(), parseFloat() and payment forms were replaced by Cortex-M ones (stale D-cache after DMA, an unclocked peripheral, a watchdog fed from a blocking task, a stale SystemCoreClock). The full guide stays available as the cmsis-developer-assistant://docs/debug_instructions resource; shipped docs are now read once per server instance.

[2.3.5] - 2026-08-24

Added

• Per-tool call telemetry — every MCP tool call is measured at the server boundary: argument and result bytes, wall time and outcome (ok / timeout / error). get_session_status now ends with a two-line summary for the session, the new cmsis-developer-assistant://stats resource returns the per-tool totals as JSON (session and server instance, plus the last 50 samples) so a test driver can diff it around a run, one INFO line per call goes to the output channel, and the new cmsis-developer-assistant.telemetry.jsonlPath setting (default off) appends one JSON line per call to a file — names and sizes only, never arguments or results. test/realboard/run.ts writes the statistics into its report. Groundwork for measuring the response-size work and for agent evaluation runs.

Also attached: cmsis-pack-docs-0.1.1.vsix — the experimental CMSIS Pack Docs extension (page-cited search over the DFP/BSP reference manuals and datasheets of the current csolution target, via its own MCP server), built to be merged into the Assistant later.

Pre-release (odd minor). Full changelog: https://github.com/MatthiasHertelArm/CMSIS-Developer-Assistant/blob/v2.3.7/CHANGELOG.md — the upstream PR for 2.3.5–2.3.7 follows.