JetBrains añadió a la versión CLion 2026.2.2 una habilidad de inteligencia artificial específica para analizar errores de Hard Fault en proyectos de sistemas embebidos basados en ARM Cortex-M. La habilidad utiliza las herramientas MCP integradas en el entorno de desarrollo para leer los registros de estado, la memoria y el código de instrucciones, y después relacionarlos con la dirección de la instrucción que provocó el fallo, en lugar de dejar al desarrollador ante un registro sin procesar que requiere un análisis manual.
La función aborda un problema común en la depuración de software embebido. Cuando ocurre un Hard Fault, el procesador se detiene porque ya no es seguro continuar ejecutando la instrucción que provocó el problema, pero el procesador no explica automáticamente la causa de la detención. Esto puede deberse al acceso a una dirección de memoria no válida o al desbordamiento de la pila, mientras que el controlador de errores predeterminado puede mostrar poco más que el hecho de que ocurrió la excepción.
¿Qué analiza la habilidad?
La habilidad se llama clion-embedded-hardfault y comienza a funcionar cuando la sesión de depuración se detiene dentro de HardFault_Handler o de controladores relacionados como MemManage_Handler, BusFault_Handler y UsageFault_Handler. También puede activarse cuando aparecen referencias a registros como CFSR, HFSR, MMFAR y BFAR, o al marco de excepción guardado por el hardware.
En lugar de pedir al agente que lea un volcado de texto de los registros del procesador, la habilidad proporciona datos previamente desglosados que incluyen los registros de estado del fallo y el marco de excepción que el hardware guardó antes de que posiblemente se sobrescribiera, además de los registros de los periféricos desglosados según los archivos SVD. Estos datos llegan junto con la memoria que rodea la instrucción causante del fallo y su desensamblado.
¿Qué cambia en la práctica?
La investigación tradicional requería descodificar manualmente CFSR y HFSR, comparar después el contador de programa causante del fallo con el desensamblado y, posiblemente, reproducir el problema varias veces para acotar la búsqueda. En CLion, el desarrollador puede ejecutar su agente preferido desde una ventana de conversación de inteligencia artificial o desde el terminal, y describir el problema en lenguaje natural después de que la sesión de depuración se detenga.
El agente utiliza las herramientas del IDE mediante MCP para acceder a las evidencias relacionadas con el estado real del procesador. Después de identificar la causa, muestra la ubicación del fallo y una descripción de la solución propuesta. El desarrollador puede corregirlo manualmente o pedir al agente que modifique el código y reinicie la sesión de depuración para verificar el resultado. La habilidad admite distintas herramientas de depuración, entre ellas Lauterbach TRACE32, Segger J-Link y ST-LINK, por lo que no está vinculada a un único proveedor.
Disponibilidad y limitaciones
La habilidad está activada de forma predeterminada en Settings | Tools | AI Assistant | Skills | Bundled skills, pero su uso requiere habilitar el servidor MCP desde Settings | Tools | MCP Server. Está disponible en los modos de conversación y terminal con Claude Code y Codex, mientras que GitHub Copilot solo es compatible con el modo de terminal.
La función está disponible en CLion 2026.2.2 y también está previsto añadirla a la próxima versión beta de la serie 2026.3 EAP. JetBrains explica que las herramientas MCP básicas no se limitan a Hard Fault: permiten a los agentes iniciar y detener sesiones de depuración, gestionar puntos de interrupción, avanzar paso a paso y leer variables locales, valores de marcos y campos anidados.
¿Por qué es importante este avance?
El valor práctico no reside en añadir otro agente al entorno de desarrollo, sino en proporcionarle evidencias corregidas y relacionadas procedentes de la propia sesión de hardware. Esto reduce la dependencia de interpretar salidas del terminal o de hacer suposiciones a partir del registro del fallo. Aun así, la función no elimina la necesidad de que el desarrollador revise el resultado: la fuente describe un mecanismo para acceder a la causa, aplicar la corrección y verificarla, pero no garantiza que la propuesta del agente sea correcta en todos los casos ni que la repetición de la prueba cubra todas las condiciones del fallo.