El Service Processor (SP) de Oxide es un microcontrolador encargado de gestionar funciones esenciales en sus racks para centros de datos, como el control térmico, la red de administración y la supervisión del hardware. Su importancia radica en que permite operar y diagnosticar el rack de forma remota, minimizando la necesidad de intervención física. Sin embargo, durante pruebas con la nueva bandeja Cosmo, el SP comenzó a desaparecer de la red, dejando al equipo sin visibilidad sobre su estado.
El SP ejecuta Hubris, un sistema operativo personalizado escrito en Rust que organiza las funciones en tareas con prioridades. Una de las hipótesis iniciales fue que una tarea, posiblemente en un bucle infinito de reinicios, estuviera acaparando la CPU e impidiendo que la tarea de red respondiera. Para verificar si el SP seguía activo, se modificó el LED del chasis para que parpadeara. Aunque se logró reproducir el fallo, el comportamiento del LED era errático: a veces se quedaba fijo encendido, otras apagado, lo que sugería que la tarea de alto nivel encargada del parpadeo estaba siendo bloqueada.
Otra línea de investigación fueron los desbordamientos de pila (stack overflow), un problema conocido en Hubris debido al dimensionado manual de las pilas de las tareas. Aunque el núcleo tenía márgenes amplios (512 bytes), un desbordamiento podría reiniciar la tarea o el sistema. Para obtener más información, se conectaron cabezales de depuración SWD, algo inusual en un sistema en producción. Con ellos, se reprodujo el fallo, pero la sonda no podía detener la CPU mediante un halt de depuración, limitando el diagnóstico.
La atención se centró entonces en un nuevo componente de la bandeja Cosmo: una FPGA conectada al SP mediante un bus paralelo controlado por el Flexible Memory Controller (FMC) del microcontrolador STM32H7. Una lectura a un registro de la FPGA que nunca completara su ciclo podría colgar el bus y, por tanto, la CPU. Para probarlo, se creó una imagen de FPGA con un registro que deliberadamente colgaba el bus, reproduciendo síntomas muy similares. La revisión de tiempos por parte de los ingenieros de hardware confirmó que no se cumplían las restricciones de temporización de la interfaz de memoria, y se aplicó una corrección.
Posteriormente, durante el desarrollo de la función de arranque medido, el fallo reapareció con una frecuencia mucho mayor (cada 10-20 minutos). Esto permitió realizar múltiples experimentos, incluyendo el uso de la captura vectorial (vector catch) de ARM, que detiene la CPU tras un reinicio sin borrar la RAM. Aunque se perdía el contador de programa, se pudo observar el estado de las tareas. Con la caché desactivada, los volcados eran consistentes, pero el fallo no se reproducía. La combinación de todas las evidencias apuntaba a un problema intermitente en el bus FMC, probablemente agravado por la caché.
Este caso ilustra cómo la depuración de sistemas embebidos en entornos reales requiere combinación de técnicas software (prioridades de tareas, volcados con vector catch) y hardware (cabezales SWD, análisis de temporización de FPGA). Las limitaciones incluyen la dificultad de reproducir fallos esporádicos y la necesidad de herramientas de depuración especializadas. Para sistemas críticos como los racks de datos, diseñar con redundancia y puntos de observación (LEDs, puertos de depuración) es clave para poder diagnosticar fallos sin interrumpir el servicio.