
McuBuddy
io.github.cunjun由 GitHub 帳號 cunjun 發布v0.5.1更新於 Oct 24, 2026
AI-native MCU debugging and observability through probes, symbols, RTOS, logs, and build tools.
概覽
本機 MCP 伺服器,讓 AI 助理偵錯真實 MCU 板卡:探針、符號、暫存器、RTOS 狀態、日誌與 Keil 建置。
- 可以做什麼
- 探索並連線偵錯探針(ST-Link、J-Link、CMSIS-DAP),控制目標執行
- 讀寫記憶體與暫存器,設定中斷點與監看點,解析 SVD 周邊暫存器欄位
- 以 ELF/DWARF 符號將位址解析為函式、原始碼行、區域變數與呼叫堆疊,用於故障診斷
- 檢視 FreeRTOS 工作、情境與堆疊使用量,讀取 UART、RTT 與 SWO 日誌
- 探索 Keil MDK 專案,透過 UV4.exe 建置或下載韌體,管理 GDB 伺服器
- 查詢工具安全分級、驗證紀錄與環境診斷資訊
- 適用情境
- 適合讓助理在真實硬體上處理嵌入式韌體:板級啟動、HardFault 與開機失敗排查、堆疊溢位或記憶體損毀分析、周邊與 RTOS 檢查,以及以證據為先的建置、燒錄、驗證流程。
- 執行需求
- 需在本機安裝 Python 3.10 以上並安裝 McuBuddy 套件,由用戶端以 stdio 程序啟動。需要已供電的 MCU 開發板、正確連接的 ST-Link、J-Link 或 CMSIS-DAP 探針、目標晶片型號,最好還有含偵錯資訊的 ELF/AXF。Keil 建置與下載需 Windows 與 Keil MDK;J-Link Python 後端需額外選用相依套件。不開放網路監聽,未宣告憑證。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 McuBuddy,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
McuBuddy — AI-Powered MCU and Embedded Firmware Debugging MCP Server
Extend AI from firmware analysis to real MCUs, closing the loop across diagnosis, code changes, build, flashing, and validation in verified environments.
McuBuddy is a Model Context Protocol (MCP) server for
MCU board-level debugging. It exposes debug probes, Keil MDK projects, ELF/DWARF symbols,
CPU and memory state, SVD peripheral registers, UART/RTT logs, FreeRTOS state, Flash operations,
and GDB servers as structured tools that AI assistants can call.
It is designed for firmware development, board bring-up, fault isolation, debugging automation, and AI-assisted validation.
McuBuddy starts with 19 stable tools in the default toolset. Add only the domains a workflow
needs with MCUBUDDY_TOOLSETS=probe,diagnose (available domains: probe, diagnose,
build_flash, rtos, logs, and experimental). The core profile is the only profile;
startup toolset selection is explicit and immutable.
[!IMPORTANT] Automation does not replace engineering responsibility. Humans remain responsible for goals and acceptance criteria, wiring and power safety, high-risk operation approval, code review, and new environment validation. Motors, relays, and other safety-related devices also require recovery plans and independent protection.
Quick links: Quick Start · Project Guide · Tool Reference · Support Matrix
✨ Key Features
- Real-hardware debugging: Discover and connect to ST-Link, J-Link, CMSIS-DAP, and other probes; control target execution; and inspect registers, memory, breakpoints, and watchpoints.
- Keil project workflow: Discover
.uvprojx/.uvprojfiles, select a target, invoke Keil MDK throughUV4.exefor builds or downloads, and feed the generated AXF/ELF into debugging. - Source-level fault diagnosis: Use ELF/DWARF data to resolve addresses to functions, source lines, local variables, and call stacks when investigating HardFaults, startup failures, stack overflows, and memory corruption.
- Peripheral and RTOS inspection: Decode peripheral registers through CMSIS-SVD and inspect FreeRTOS tasks, task contexts, and stack usage.
- Logs and runtime observability: Read UART, RTT, and selected J-Link SWO logs, and manage pyOCD/J-Link GDB server lifecycles.
- Evidence-driven results: Return structured target, state, and validation evidence so AI can continue an investigation instead of guessing code changes from symptoms alone.
- Actionable hardware boundaries: Distinguish MCU limitations, firmware-inapplicable tools, configuration problems, tool failures, and insufficient evidence, including impact and the next safe check so unsupported paths are not debugged as firmware defects.
🏗️ How It Works
MCP is not a protocol for invoking Keil. The AI calls McuBuddy through MCP; McuBuddy then
uses Keil MDK through UV4.exe, pyOCD, J-Link, or another internal backend as required.
🚀 Quick Start
1. Prerequisites
Basic requirements:
- Python 3.10 or later;
- a powered MCU development board;
- a correctly connected ST-Link, J-Link, or CMSIS-DAP probe;
- the target chip name;
- preferably, an ELF/AXF image containing debug information.
Keil build and download features require Windows with Keil MDK installed. McuBuddy invokes
µVision through UV4.exe, including in Keil MDK v5 installations.
2. Installation
This installs McuBuddy once for all local firmware projects. Do not clone or copy the McuBuddy
repository into each target project. McuBuddy is a local-only MCP backend: the client starts one
stdio process per connection, and McuBuddy does not expose HTTP, SSE, WebSocket, or another MCP
network listener.
The target project, Keil installation, ELF/SVD files, probe, and serial port must be directly
visible to the machine running McuBuddy. To update, reinstall from the official repository at
https://github.com/cunjun/McuBuddy; McuBuddy never checks for, downloads, or installs updates
automatically.
Install the optional dependency when using the J-Link Python backend:
For development from source:
3. Configure an MCP Client
For a Windows source checkout, explicitly configure the virtual-environment Python executable and working directory. See Installation and First Connection, then restart the AI client.
4. Run a First Read-Only Check
After connecting the probe and powering the board, tell the AI:
The recommended sequence is to check the environment and target first, then configure the probe and read the minimum target state:
probe_connect and read_stopped_context are available in the default core profile. Reading a
stable stopped context may halt the target, so it is still execution-changing. If the device must
not be halted, instruct the AI to perform only non-intrusive probe and environment checks.
💬 Automated Debugging Example
For the evidence-first decision order and common scenarios, see Common Debugging Workflows.
🧰 Backends and Hardware Validation
Primary validation coverage includes:
- STM32L496VETx + ST-Link / pyOCD;
- STM32F103C8 + J-Link;
- built-in target preflight profiles for STM32F103ZE and PY32F030X8.
“Implemented in code” does not mean “validated on every board.” Use the
Support Matrix and list_validation_records() as the source of truth.
🛡️ Safety Model
McuBuddy provides machine-readable safety classifications through list_tool_safety().
Safety principles:
- For an unknown target, match the chip and probe first; do not guess addresses.
- Read evidence before halting, resetting, or writing.
- Before a Flash operation, confirm the target, scope, image, and recovery method.
- For motors, relays, power switches, and other actuators, prefer breakpoints and low-energy tests.
- Send actuator commands with
uart_send_with_cleanup, then callfinish_debug_sessionbefore returning a final conclusion. Server shutdown repeats the same idempotent cleanup as a fallback.
🔒 Sessions and Concurrency
- Operations that share probe, Keil, ELF/SVD, log, and runtime configuration are serialized within
the same
Session. - Different sessions can run concurrently when they control unrelated boards.
- Stateless queries such as target matching and tool safety information can run alongside session operations.
- Cancellation cannot forcibly terminate a call that has entered a synchronous SDK. The server waits for the worker thread to finish before releasing the session lock.
This prevents one request from switching backends, disconnecting the probe, or changing shared state while another probe operation is still running.
📦 mcubuddy Skill
The repository includes skills/mcubuddy, which guides Codex and Claude Code to use these tools in an
“evidence first, judgment second” sequence instead of treating MCP tools as an unordered command list.
The Skill is an optional workflow enhancement, not a prerequisite for hardware debugging. A correctly installed and configured local McuBuddy MCP server remains fully usable without it.
Installed releases bundle the Skill. Register the persistent Codex integration without cloning the repository:
Install for Codex:
Install for Claude Code:
Restart the client or open a new session after installation. For source-checkout recovery, installation registration, and usage boundaries, see Boundaries Between McuBuddy, MCP, and the Skill for details.
⚠️ Current Limitations
- Keil build and download currently require Windows with Keil MDK and invoke µVision through
UV4.exe, including in MDK v5 installations. - The probe-rs sidecar covers Flash and RTT but still requires target-specific real-board validation and does not yet have an official binary release.
- RTOS inspection depends on FreeRTOS symbols and an ELF/AXF that match the target firmware.
- SVD files are not bundled automatically for every chip and usually come from a CMSIS-Pack or the chip vendor.
- SWO text capture depends on chip configuration, probe capabilities, pin multiplexing, and board wiring.
- Device patches and connection strategies remain lightweight mechanisms rather than a complete board plugin system.
📚 Documentation
- Complete project overview and workflows: Project Guide
- Chinese project overview: 项目指南
- Complete tool index: Tool Reference
- Chinese tool usage: MCP 工具中文参考
- Backend and hardware validation: Support Matrix
- Project design: Architecture
- Release history: Changelog
🧪 Local Development
See the Project Guide for repository layout and documentation ownership.
🙏 Upstream and Acknowledgements
McuBuddy is based on SolarWang233/mcudbg and continues its MIT-licensed work with additional architecture, safety boundaries, evidence workflows, backend support, and documentation. The original copyright notice is preserved in LICENSE, with provenance details in NOTICE.
📄 License
This project is licensed under the MIT License. See LICENSE for details.
If McuBuddy helps with your MCU debugging workflow, consider giving the project a Star.
If you have suggestions, open an Issue or email
[email protected].
來源:README.md,提交 85d7f9a
工具
0版本歷史
1- v0.5.1最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分