{"type": "text"}

stm32-stlink-mcp

STM32マイクロコントローラをST-LINK経由でデバッグするためのMCPサーバーで、STMicroelectronics純正のSTM32CubeCLTツールセット（ST-LINK_gdbserver、STM32_Programmer_CLI、arm-none-eabi-gdb（GDB/MI2経由で駆動））を基に構築されています。OpenOCD、J-Link、probe-rsは使用しません。

Architecture

デバッグセッションは、STが公式に文書化したワークフロー（UM2576、「STM32CubeIDE ST-LINK GDB server」）を正確にミラーリングした、2つの子プロセスのペアです：

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

arm-none-eabi-gdbはMI2モードで駆動されるため、サーバーはGDB Remote Serial Protocolを手動で実装する代わりに、ソースレベルステップ、シンボリックブレークポイント、シンボル対応の式評価を無料で利用できます。ST-LINK_gdbserverはセッションの存続期間中、プローブへのUSBハンドルを保持します。gdbのload（MI: -target-download）によるフラッシュは、サーバーによってSTM32CubeProgrammerに透過的に委任されるため、再フラッシュのためにセッションを終了する必要はありません。スタンドアロンのワンショットフラッシュ（flash_standalone、セッション不要）はSTM32_Programmer_CLIを直接呼び出すため、同じプローブ上の既存セッションと競合します — ツールの説明を参照してください。

Related MCP server: dbgprobe-mcp-server

Setup

npm install
npm run build

STM32CubeCLTがインストールされ、そのbin/ディレクトリにアクセス可能である必要があります — すでにPATH上にあるか（CLTインストーラーがデフォルトでこれを行います）、またはSTMCP_CUBECLT_PATH/ツールごとのオーバーライドを介して。確認するにはnpm run doctorを実行してください。

Running

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

Registering with an MCP client

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

Configuration (environment variables)

Tools

Deferred to v2

SVDペリフェラルレジスタツール（memory_read/write + evaluate_expressionはすでにアドレスですべてにアクセス可能）、ライブ/ストリーミングメモリポーリング、プラグインシステム、チップごとのメモリ領域許可リスト、任意のgdb monitorパススルー、およびオプションバイト/RDPツール（ブリック可能、意図的にスコープ外）

RTT

RTT（SEGGER Real Time Transfer — ライブで非停止のコンソール/変数トレース）は、このサーバーでは意図的に実装されていません。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>" }
    }
  }
}

strtt_startをtcp: trueで開始すると、USBデバイスを直接要求する代わりに共有ST-LINKサーバーを介して接続します — これにより、GdbServerProcessが常に-t/--sharedをST-LINK_gdbserverに渡すため、ここで開いているdebug_connectセッションと並行して実行できます。tcp: trueがない場合、strttと開いているデバッグセッションは同じプローブをめぐって競合します。

Hardware verification runbook

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を停止させます。予期しない停止が安全でない方法でアクチュエータ/出力を積極的に駆動しているボードには、事前に確認せずに接続しないでください。