JetBrains hat der Version CLion 2026.2.2 eine spezielle KI-Fähigkeit zur Analyse von Hard-Fault-Fehlern in eingebetteten Projekten auf Basis von ARM Cortex-M hinzugefügt. Die Fähigkeit verwendet die in der Entwicklungsumgebung integrierten MCP-Tools, um Statusregister, Speicher und Codeanweisungen zu lesen und sie anschließend mit der Adresse der Anweisung zu verknüpfen, die den Fehler verursacht hat, anstatt den Entwickler mit einem Rohprotokoll zurückzulassen, das manuell analysiert werden muss.
Die Funktion zielt auf ein häufiges Problem beim Debuggen eingebetteter Software. Wenn ein Hard Fault auftritt, hält der Prozessor an, weil eine Fortsetzung der Ausführung der problematischen Anweisung nicht mehr sicher ist; der Prozessor erklärt jedoch nicht automatisch den Grund für den Halt. Ursache kann der Zugriff auf eine ungültige Speicheradresse oder ein Überlaufen des Stacks sein, während der standardmäßige Fehler-Handler möglicherweise nicht mehr als die Tatsache anzeigt, dass eine Ausnahme aufgetreten ist.
Was analysiert die Fähigkeit?
Die Fähigkeit trägt den Namen clion-embedded-hardfault und nimmt ihre Arbeit auf, wenn die Debugsitzung innerhalb von HardFault_Handler oder zugehörigen Handlern wie MemManage_Handler, BusFault_Handler und UsageFault_Handler angehalten wird. Sie kann außerdem aktiviert werden, wenn Hinweise auf Register wie CFSR, HFSR, MMFAR und BFAR oder auf den auf der Hardware gespeicherten Ausnahme-Stackframe vorliegen.
Anstatt den Agenten aufzufordern, einen Text-Dump der Prozessorregister zu lesen, stellt die Fähigkeit bereits aufbereitete Daten bereit. Dazu gehören Fehlerstatusregister, der Ausnahme-Stackframe, den die Hardware gespeichert hat, bevor er möglicherweise überschrieben wird, sowie anhand von SVD-Dateien aufbereitete Register der Peripheriemodule. Diese Daten werden zusammen mit dem Speicher im Umfeld der fehlerverursachenden Anweisung und ihrer Disassemblierung bereitgestellt.
Was ändert sich in der Praxis?
Die herkömmliche Untersuchung erforderte das manuelle Dekodieren von CFSR und HFSR und anschließend den Vergleich des für den Fehler verantwortlichen Programmzählers mit der Disassemblierung. Möglicherweise musste der Entwickler das Problem mehrfach reproduzieren, um den Suchbereich einzugrenzen. In CLion kann der Entwickler dagegen nach dem Anhalten der Debugsitzung seinen bevorzugten Agenten über das KI-Chatfenster oder das Terminal starten und das Problem in natürlicher Sprache beschreiben.
Der Agent verwendet IDE-Tools über MCP, um auf die mit dem tatsächlichen Zustand des Prozessors verbundenen Belege zuzugreifen. Nach der Ermittlung der Ursache zeigt er die Fehlerstelle und eine Beschreibung der vorgeschlagenen Lösung an. Der Entwickler kann den Fehler manuell beheben oder den Agenten auffordern, den Code zu ändern und die Debugsitzung erneut zu starten, um das Ergebnis zu überprüfen. Die Fähigkeit unterstützt verschiedene Debugging-Tools, darunter Lauterbach TRACE32, Segger J-Link und ST-LINK, und ist damit nicht an einen einzigen Anbieter gebunden.
Verfügbarkeit und Einschränkungen
Die Fähigkeit ist standardmäßig unter Settings | Tools | AI Assistant | Skills | Bundled skills aktiviert. Ihre Nutzung erfordert jedoch die Aktivierung des MCP-Servers unter Settings | Tools | MCP Server. Sie ist im Chat- und im Terminalmodus mit Claude Code und Codex verfügbar, während GitHub Copilot nur im Terminalmodus unterstützt wird.
Die Funktion ist in CLion 2026.2.2 verfügbar und soll außerdem in die erste kommende Betaversion der Reihe 2026.3 EAP aufgenommen werden. JetBrains weist darauf hin, dass die grundlegenden MCP-Tools nicht auf Hard Faults beschränkt sind. Sie ermöglichen Agenten, Debugsitzungen zu starten und zu stoppen, Haltepunkte zu verwalten, schrittweise zu navigieren sowie lokale Variablen, Frame-Werte und verschachtelte Felder zu lesen.
Warum ist diese Entwicklung wichtig?
Der praktische Wert liegt hier nicht darin, der Entwicklungsumgebung einen weiteren Agenten hinzuzufügen, sondern darin, ihn mit aufbereiteten und miteinander verknüpften Belegen aus derselben Hardwaresitzung zu versorgen. Dadurch wird die Abhängigkeit von der Interpretation von Terminalausgaben oder von Vermutungen ausgehend vom Absturzprotokoll verringert. Dennoch entfällt durch die Funktion nicht die Notwendigkeit einer Überprüfung durch den Entwickler. Die Quelle beschreibt einen Mechanismus, um die Ursache zu ermitteln, die Korrektur anzuwenden und sie zu überprüfen, gibt jedoch keine Garantie dafür, dass der Vorschlag des Agenten in jedem Fall korrekt ist oder dass ein erneuter Test alle Fehlerbedingungen abdeckt.