JetBrains a ajouté à la version CLion 2026.2.2 une compétence d’intelligence artificielle dédiée à l’analyse des erreurs de Hard Fault dans les projets de systèmes embarqués fondés sur ARM Cortex-M. Cette compétence utilise les outils MCP intégrés à l’environnement de développement pour lire les registres d’état, la mémoire et les instructions du programme, puis les mettre en relation avec l’adresse de l’instruction à l’origine de la panne, au lieu de laisser le développeur face à un journal brut nécessitant une analyse manuelle.
Cette fonctionnalité cible un problème courant dans le débogage des logiciels embarqués. Lorsqu’un Hard Fault survient, le processeur s’arrête, car il n’est plus sûr de poursuivre l’exécution de l’instruction à l’origine du problème, mais il n’explique pas automatiquement la raison de l’arrêt. Celui-ci peut être dû à l’accès à une adresse mémoire invalide ou au débordement de la pile, tandis que le gestionnaire d’erreurs par défaut peut ne faire apparaître rien de plus que le fait que l’exception s’est produite.
Qu’analyse la compétence ?
La compétence porte le nom de clion-embedded-hardfault et commence à fonctionner lorsqu’une session de débogage s’arrête dans HardFault_Handler ou dans des gestionnaires associés tels que MemManage_Handler, BusFault_Handler et UsageFault_Handler. Elle peut également être activée lorsque des références sont faites à des registres tels que CFSR, HFSR, MMFAR et BFAR, ou à la trame d’exception enregistrée par le matériel.
Au lieu de demander à l’agent de lire un vidage textuel des registres du processeur, la compétence fournit des données déjà décodées, notamment les registres d’état de l’erreur et la trame d’exception enregistrée par le matériel avant qu’elle ne soit éventuellement écrasée, ainsi que les registres décodés des périphériques conformément aux fichiers SVD. Ces données sont fournies avec la mémoire entourant l’instruction à l’origine de l’erreur et son désassemblage.
Qu’est-ce qui change concrètement ?
L’investigation traditionnelle nécessitait de décoder manuellement CFSR et HFSR, puis de comparer le compteur de programme à l’origine de la panne avec le désassemblage, et le développeur pouvait devoir reproduire le problème plusieurs fois afin de réduire le champ de recherche. Dans CLion, le développeur peut lancer son agent préféré depuis la fenêtre de conversation de l’assistant d’IA ou depuis le terminal, et décrire le problème en langage naturel après l’arrêt de la session de débogage.
L’agent utilise les outils de l’IDE via MCP pour accéder aux éléments associés à l’état réel du processeur. Après avoir déterminé la cause, il affiche l’emplacement du problème et une description de la solution proposée. Le développeur peut alors le corriger manuellement ou demander à l’agent de modifier le code et de relancer la session de débogage afin de vérifier le résultat. La compétence prend en charge différents outils de débogage, notamment Lauterbach TRACE32, Segger J-Link et ST-LINK, ce qui la rend indépendante d’un fournisseur particulier.
Disponibilité et limites
La compétence est activée par défaut dans les paramètres Settings | Tools | AI Assistant | Skills | Bundled skills, mais son utilisation nécessite l’activation du serveur MCP depuis Settings | Tools | MCP Server. Elle est disponible dans les modes conversation et terminal avec Claude Code et Codex, tandis que GitHub Copilot est pris en charge uniquement en mode terminal.
La fonctionnalité est disponible dans CLion 2026.2.2 et devrait également être ajoutée à la prochaine version bêta de la série 2026.3 EAP. JetBrains précise que les outils MCP fondamentaux ne se limitent pas au Hard Fault : ils permettent aux agents de démarrer et d’arrêter des sessions de débogage, de gérer les points d’arrêt, d’effectuer une exécution pas à pas et de lire les variables locales, les valeurs des trames et les champs imbriqués.
Pourquoi cette évolution est-elle importante ?
La valeur pratique ne réside pas dans l’ajout d’un agent supplémentaire à l’environnement de développement, mais dans le fait de lui fournir des éléments corrigés et corrélés provenant directement de la session matérielle. Cela réduit la dépendance à l’interprétation des sorties du terminal ou aux suppositions fondées sur le journal du plantage. Toutefois, cette fonctionnalité ne supprime pas la nécessité d’une vérification par le développeur : la source décrit un mécanisme permettant d’identifier la cause, d’appliquer le correctif et de le vérifier, mais ne garantit pas que la proposition de l’agent sera correcte dans tous les cas ni que le nouveau test couvrira toutes les conditions de la panne.