Problemas Conocidos

Fecha de análisis: 2026-06-27 Última actualización: 2026-06-27 Total: 7 issues — 0 críticos, 3 moderados, 4 leves

Correcciones Recientes ✅

ID	Fecha	Descripción
—	—	—

No se han encontrado issues críticos.

Archivo: h3lis.c:107-137, main.c:7-9
Descripción: h3lis_update() se llama desde sys_tick_handler() a 1 kHz y ejecuta una ráfaga SPI de 6 bytes (más overhead de CS y direccionamiento). Aunque la transacción completa (~12 µs a 5.25 MHz) cabe holgadamente en la ventana de 1 ms, las operaciones SPI bloqueantes en contexto de interrupción son frágiles: si el periférico SPI se cuelga o si otra ISR de mayor prioridad interrumpe la transacción, el sistema puede quedar bloqueado o generar datos corruptos.
Impacto: Medio — no bloquea el sistema en condiciones normales, pero reduce la robustez y complica la depuración.
Mitigación actual: Ninguna. La ISR del SysTick es la de mayor prioridad software (grupo 1), y USART1 está en prioridad 2, por lo que no hay riesgo de preempción por USART.
Solución propuesta: Mover la lectura SPI a un flag activado por SysTick y ejecutar h3lis_update() en el bucle principal, o usar SPI con DMA para descargar la CPU.

Archivo: h3lis.h:23, main.c:19
Descripción: El firmware espera WHO_AM_I = 0x33 (H3LIS_DEVICE_ID), pero el datasheet del H3LIS331DL indica que el valor esperado es 0x32. El propio README reconoce esta ambigüedad: "Debe devolver 0x32 (o 0x33 en ciertos casos)". Si el sensor real devuelve 0x32, h3lis_init() fallará y el firmware entrará en el bucle de error indefinidamente.
Impacto: Medio — impide el funcionamiento si el silicio devuelve 0x32 en lugar de 0x33.
Mitigación actual: El firmware imprime el valor real de WHO_AM_I en el mensaje de error, facilitando el diagnóstico.
Solución propuesta: Aceptar ambos valores (0x32 y 0x33) como válidos, o verificar contra una máscara de revisión (0xF0) si la familia de chips comparte los bits altos.

Archivo: h3lis.c:115,123
Descripción: h3lis_update() llama a sqrtf() dos veces (líneas 115 y 123) dentro de la ISR del SysTick. En Cortex-M4, las operaciones FPU en contexto de interrupción requieren guardar y restaurar los registros de coma flotante (S0-S31, 128 bytes), lo que añade latencia a la ISR y a cualquier ISR anidada. Aunque el impacto en rendimiento es bajo (la FPU del M4 es rápida), contribuye al jitter del sistema.
Impacto: Medio — latencia adicional en ISR. No es un bug funcional pero sí una práctica desaconsejada en sistemas de tiempo real estrictos.
Mitigación actual: Ninguna.
Solución propuesta: Marcar la ISR con __attribute__((naked)) y gestionar el contexto FPU manualmente, o mover los cálculos con sqrtf() al bucle principal. Alternativamente, usar una LUT para sqrtf() en el rango esperado de operación.

Archivo: delay.h:8, setup.h:13
Descripción: delay.h incluye setup.h, y setup.h incluye delay.h. Los include guards evitan la recursión infinita, pero esta dependencia bidireccional indica que las responsabilidades no están bien separadas. delay.h solo necesita stdint.h y dwt.h — no necesita incluir setup.h.
Impacto: Bajo — no causa errores de compilación gracias a los include guards, pero dificulta el mantenimiento y análisis de dependencias.
Mitigación actual: Include guards (#ifndef __DELAY_H, #ifndef __SETUP_H).
Solución propuesta: Eliminar #include "setup.h" de delay.h. Las dependencias reales son stdint.h y libopencm3/cm3/dwt.h, que ya están incluidas.

Archivo: usart.c:18-19
Descripción: La conversión de \n a \r\n está comentada. En terminales serie que no realizan conversión automática (como screen o minicom sin flags adecuados), la salida de printf mostrará un efecto escalera (cada línea empieza donde terminó la anterior en lugar de en la columna 0).
Impacto: Bajo — solo afecta la legibilidad de la salida serie en ciertos terminales. La mayoría de terminales modernos y pio device monitor manejan \n correctamente.
Mitigación actual: El monitor de PlatformIO (monitor_speed = 115200) típicamente maneja la conversión.
Solución propuesta: Descomentar las líneas 18-19 si se usa un terminal que requiera \r\n.

Archivo: delay.c:30
Descripción: delay_us() calcula los ciclos de espera con aritmética de punto flotante:
```
uint32_t sleep_cycles = (uint32_t)(SYSCLK_FREQUENCY_HZ * ((float)us / (float)MICROSECONDS_PER_SECOND));
```
Con SYSCLK_FREQUENCY_HZ = 84000000 y MICROSECONDS_PER_SECOND = 1000000, esto equivale a us * 84. Se puede reemplazar por aritmética entera:
```
uint32_t sleep_cycles = us * (SYSCLK_FREQUENCY_HZ / MICROSECONDS_PER_SECOND);
```
Impacto: Bajo — la operación flotante añade algunos ciclos de CPU pero delay_us() no se usa en la ISR, así que no afecta al tiempo real.
Mitigación actual: Ninguna necesaria — funciona correctamente.
Solución propuesta: Reemplazar con aritmética entera para claridad y eficiencia.

Archivo: main.c:19-20
Descripción: En el camino de error (sensor no detectado), h3lis_who_am_i() se llama hasta 3 veces: una en la condición if, otra en el printf del if, y potencialmente otra en el printf del else. Cada llamada realiza una transacción SPI completa. Como el sensor no responde, estas transacciones son tiempo perdido.
Impacto: Bajo — solo ocurre durante el arranque en caso de error.
Mitigación actual: Ninguna.
Solución propuesta: Guardar el resultado de h3lis_who_am_i() en una variable local antes del if:
```
uint8_t who = h3lis_who_am_i();
if (who != H3LIS_DEVICE_ID) { ... }
```

Documento generado el 2026-06-27. Los issues se añaden y actualizan mediante /doc-review al auditar el código fuente.