stm32-stlink-mcp

用于通过 ST-LINK 调试 STM32 微控制器的 MCP 服务器，基于 STMicroelectronics 自家的 STM32CubeCLT 工具集构建——ST-LINK_gdbserver、STM32_Programmer_CLI 和 arm-none-eabi-gdb（通过 GDB/MI2 驱动）。不涉及 OpenOCD、J-Link 或 probe-rs。

架构

调试会话由一对子进程组成，精确复刻 ST 官方文档描述的工作流程（UM2576，"STM32CubeIDE ST-LINK GDB server"）：

 arm-none-eabi-gdb  --interpreter=mi2  --(TCP, target extended-remote)-->  ST-LINK_gdbserver  --(USB)-->  ST-LINK  --(SWD)-->  STM32

arm-none-eabi-gdb 以 MI2 模式驱动，因此服务器无需自行实现 GDB 远程串行协议，即可免费获得源码级单步、符号断点和符号感知的表达式求值。ST-LINK_gdbserver 在会话生命周期内持有探针的 USB 句柄；通过 gdb 的 load（MI：-target-download）进行的烧录由服务器透明地委托给 STM32CubeProgrammer，因此重新烧录无需拆除会话。独立的一次性烧录（flash_standalone，无需会话）直接调用 STM32_Programmer_CLI，因此会与同一探针上已打开的会话冲突——请参阅工具描述。

Related MCP server: dbgprobe-mcp-server

安装

npm install
npm run build

需要安装 STM32CubeCLT 并确保其 bin/ 目录可访问——要么已经位于 PATH 中（CLT 安装程序默认会这样做），要么通过 STMCP_CUBECLT_PATH / 按工具的覆盖路径指定。运行 npm run doctor 进行检查。

运行

node dist/index.js serve     # starts the MCP server on stdio (default mode)
node dist/index.js doctor    # pre-flight check: tool resolution, connected probes, udev rules
node dist/index.js doctor --json

向 MCP 客户端注册

{
  "mcpServers": {
    "stm32-stlink": {
      "command": "node",
      "args": ["<path-to-this-repo>/stmcp/dist/index.js"]
    }
  }
}

配置（环境变量）

工具

推迟到 v2

SVD 外设寄存器工具（memory_read/write + evaluate_expression 已经可以通过地址访问一切）、实时/流式内存轮询、插件系统、按芯片划分的内存区域白名单、任意 gdb monitor 透传，以及选项字节/RDP 工具（可能导致变砖，有意不在范围内）。

RTT

RTT（SEGGER 实时传输——实时、不暂停内核的控制台/变量跟踪）有意不在此服务器中实现。ST-LINK_gdbserver 的 GDB/MI 存根没有非停止模式，因此通过此服务器的 debug_connect 会话读取内存需要先暂停内核——这违背了 RTT 的目的。正确的机制是永不暂停内核的直接 AP 内存访问（通过阅读 ST 自家的 STM32CubeMonitor 源码确认，它正是使用这种方式，STM32_Programmer_CLI 的 -r32fast 也是如此）。

这正是 strtt 已经实现的功能，strtt-mcp 将其封装为独立的 MCP 服务器（strtt_start/strtt_stop/strtt_status/strtt_read/strtt_write）。请将其与此服务器并列注册，而不是通过它注册：

{
  "mcpServers": {
    "stm32-stlink": { "command": "node", "args": ["<...>/mcp-server/dist/index.js"] },
    "strtt": {
      "command": "node",
      "args": ["<path-to-strtt-repo>/mcp/dist/index.js"],
      "env": { "STRTT_BIN": "<path-to-strtt-binary>" }
    }
  }
}

使用 tcp: true 启动 strtt_start，通过共享的 ST-LINK Server 连接，而不是直接占用 USB 设备——这样它就可以与此处打开的 debug_connect 会话并发运行，因为 GdbServerProcess 总是将 -t/--shared 传递给 ST-LINK_gdbserver。如果不使用 tcp: true，strtt 和已打开的调试会话将争用同一个探针。

硬件验证手册

连接好 ST-LINK 和目标板后：

node dist/index.js doctor                     # confirm probe + tools resolve
npx @modelcontextprotocol/inspector node dist/index.js   # interactive tool testing

然后，通过检查器或 MCP 客户端：

1. list_probes → 探针的序列号会出现。

2. debug_connect { elfPath, device, interface: "swd", serial } → 返回一个 sessionId。

3. breakpoint_set { sessionId, location: "main" } → 返回一个断点编号。

4. debug_run { sessionId } → 以 reason: "breakpoint-hit" 暂停。

5. register_read { sessionId, registers: ["pc","sp","lr","r0"] }。

6. evaluate_expression { sessionId, expression: "<a known global>" }。

7. read_fault_registers { sessionId } → 复位后标志为良性/零值。

8. debug_disconnect { sessionId } → 确认没有孤儿进程：ps aux | grep -E 'ST-LINK_gdbserver|arm-none-eabi-gdb'。

9. flash_standalone { file, reset: "hard", run: true }，且没有打开的会话。

10. 负向测试：打开一个会话，然后在同一序列号上调用 flash_standalone → 预期返回 DEVICE_BUSY。

注意： debug_connect 会暂停目标 CPU。如果电路板正在主动驱动执行器/输出，且意外暂停可能不安全，请勿在未事先确认可行的情况下连接。