Embedded Debugger MCP : déboguer une carte embarquée via une sonde

Pour qui

Si vous voulez confier le débogage d'une carte embarquée à un agent plutôt que de d'abord configurer un débogueur graphique complet, ce service correspond. C'est un serveur MCP en Rust qui peut faire la découverte de sondes, le contrôle de cible, la lecture mémoire, les points d'arrêt, le flashage, RTT et un diagnostic de plantage orienté agent, via probe-rs ou le GDB Remote Serial Protocol d'OpenOCD. Il inclut aussi une petite ligne de commande et un flux d'empaquetage utilisables avant de brancher un client MCP. Ce n'est pas un manuel de puce et il ne soude pas les fils.

Notes officielles :

https://github.com/adancurusul/embedded-debugger-mcp

Préalable essentiel : le travail matériel exige une sonde compatible, ou un openocd déjà lancé qui expose un port GDB, plus un câblage SWD/JTAG utilisable. Le texte officiel nomme ST-Link, J-Link, DAPLink, Black Magic Probe ou une sonde FTDI prise en charge ; ESP32 peut utiliser openocd-esp32. Sans sonde, ne commencez pas à flasher.

Premier essai en 3 minutes

Une seule voie officielle : cloner le dépôt, puis construction Cargo en release.

Préalable : Rust / cargo installés. Le travail matériel exige aussi la sonde ou OpenOCD ci-dessus. Le premier essai est la découverte seulement — ne programmez pas flash.

Cloner d'abord :

https://github.com/adancurusul/embedded-debugger-mcp.git

Commande d'installation :

cargo build --release

Le binaire est dans target/release/embedded-debugger-mcp.

Où configurer : le client MCP pose la commande à embedded-debugger-mcp serve. Par compatibilité, lancer le binaire sans sous-commande sert aussi MCP sur stdio. Les extraits ne disent pas quel client est obligatoire ; n'ajoutez pas de liste de noms.

Premier appel à bas risque : découverte de sondes seulement. Cela énumère les sondes locales, ce n'est ni un halt ni un flash. Si vous touchez la cible, confirmez d'abord le câblage. Les outils diagnose_fault et unwind_exception lisent le site d'exception et peuvent encore affecter un micrologiciel en cours — ne les utilisez pas au premier essai.

Signal de succès : la construction release se termine, le client peut lever serve, et la découverte renvoie un inventaire de sondes ou un ensemble clairement vide. Si seul Cargo échoue, arrêtez à la construction ; ne passez pas à flash.

Cas d'usage

Cas 1 : faire la découverte de sondes et confirmer si un ST-Link, J-Link ou autre compatible est vu. Le texte officiel place probe discovery en tête du jeu d'outils. Vous pouvez vérifier si l'inventaire montre la sonde branchée. Les extraits n'écrivent ni le nom exact de fonction ni les paramètres ; n'inventez pas ce qui manque.

Cas 2 : une fois la cible déjà connectée, utiliser diagnose_fault ou unwind_exception pour un plantage. Le texte officiel les écrit comme crash diagnosis. Convient quand la carte est déjà arrêtée dans une exception et que l'agent doit lire le contexte de faute. Accès mémoire et RTT sont dans le même jeu, mais cette page n'étend ni largeurs de lecture/écriture ni formats de tampon. Jusqu'ici, seule l'existence des noms de diagnostic est sûre. flash programming et breakpoints sont des écritures à effets de bord — pas pour le premier exemple.

Limites d'usage

Sans sonde ou sans câblage SWD/JTAG, le travail matériel est impossible. Le chemin OpenOCD exige un processus déjà lancé qui expose un port GDB, par exemple ESP32 avec openocd-esp32. Flashage, points d'arrêt et halt changent l'état de la cible. Ce n'est pas un risque nul, ni « sans toucher le matériel », ni « sans lire la mémoire ».

Le texte officiel mentionne aussi Cortex-M, RISC-V et Xtensa, mais cette page n'a ni inventaire de puces ni étapes d'annulation. Ce guide ne couvre que la construction Cargo release, stdio serve, découvrir d'abord puis diagnostiquer au besoin. Si un autre flux n'est pas écrit sur la même page, n'extrapolez pas.