Problemas Conocidos

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

Correcciones Recientes ✅

ID	Fecha	Descripción
—	—	—

No se han encontrado issues críticos.

Archivo: sram.c:265
Descripción: snprintf usa %ld (espera signed long) para formatear header.bytes_used y RECORDS_AREA_SIZE, ambos uint32_t. En ARM32 con newlib-nano, uint32_t es unsigned int, no unsigned long. Aunque ambas son 32 bits en esta plataforma, el especificador correcto es %" PRIu32 " o %lu con cast explícito a unsigned long. Si bytes_used llegara a superar 2³¹ (524288 máx, no aplica aquí), se imprimiría como negativo. Además, el tercer argumento RECORDS_AREA_SIZE también usa %ld con tipo unsigned long.
Impacto: Bajo en la práctica (los valores nunca superan 2³¹), pero es undefined behavior según el estándar C.
Mitigación actual: Ninguna.
Solución propuesta: Cambiar a %" PRIu32 "/%" PRIu32 " Bytes (%.2f%%)" con #include <inttypes.h>, o castear a unsigned long y usar %lu.

Archivo: sram.c:261
Descripción: La condición header.bytes_used >= RECORDS_AREA_SIZE hace que cuando el buffer está exactamente lleno (bytes_used == RECORDS_AREA_SIZE), la función retorne la cadena "0" en lugar de mostrar "524272/524272 Bytes (100.00%)". El mensaje "0" es engañoso — sugiere que el buffer está vacío cuando en realidad está completamente lleno.
Impacto: Medio — puede confundir al usuario sobre el estado real de la SRAM.
Mitigación actual: Ninguna.
Solución propuesta: Eliminar la condición header.bytes_used >= RECORDS_AREA_SIZE del early return, o cambiar el límite a > estricto. El snprintf ya formatea correctamente el 100%.

Archivo: sram.c:264
Descripción: La función usa un static char buf[32] para formatear el string de uso. Si se llama desde un ISR y desde el contexto principal simultáneamente, el buffer podría corromperse. En la demo actual no hay ISRs que llamen a esta función, pero es frágil para uso futuro en sistemas con RTOS o múltiples hilos.
Impacto: Bajo en el contexto actual (demo mono-hilo).
Mitigación actual: Ninguna.
Solución propuesta: Aceptar un buffer externo como parámetro (char *buf, size_t buf_size), o devolver los valores numéricos para que el caller los formatee.

Archivo: sram.c:237
Descripción: Para contar registros de un tipo específico, la función crea un iterador y recorre TODOS los registros de la SRAM, leyendo cada cabecera por SPI. Con muchos registros esto es lento — cada iteración requiere al menos 3 bytes de lectura SPI (~2.3 µs a 10.5 MHz). Para 10000 registros, el conteo tarda ~23 ms. sram_get_total_records() no tiene este problema porque lee directamente de la cabecera (O(1)).
Impacto: Bajo en demos con pocos registros. Puede ser relevante si se usa en robots con logging intensivo.
Mitigación actual: Ninguna.
Solución propuesta: Mantener contadores por tipo en la cabecera de la SRAM (requiere cambiar el formato de la cabecera), o usar sram_get_total_records() + SRAM_TYPE_ANY cuando no se necesita filtrar por tipo.

Archivo: delay.c:17
Descripción: La función delay() calcula awake = clock_ticks + ms. Si clock_ticks está cerca de UINT32_MAX (0xFFFFFFFF) y ms causa wrap-around, awake será pequeño y el bucle while (awake > clock_ticks) terminará inmediatamente. Esto ocurre tras ~49.7 días de uptime continuo (2³² ms). delay_us() no tiene este problema porque usa el DWT cycle counter de 32 bits con resta modular (b - a <= limit).
Impacto: Irrelevante para una demo — ningún demo funciona 50 días seguidos.
Mitigación actual: Ninguna.

Solución propuesta: Usar resta modular como en delay_us():

uint32_t start = clock_ticks;
while ((clock_ticks - start) < ms) {};

Archivo: setup.c:41, setup.c:51-52, usart.c:18-19
Descripción: Varias funcionalidades están deshabilitadas con comentarios: IRQ de USART1 RX, interrupción EXTI15_10, inserción de \r antes de \n en _write(). Esto es intencionado para simplificar la demo, pero indica que el código no está en su estado final para uso en producción. Si se habilita la recepción USART, hay que añadir un handler de IRQ y un buffer de recepción.
Impacto: Bajo — simplificación intencionada para la demo.
Mitigación actual: N/A (es una decisión de diseño consciente).

Documento generado el 2026-06-27. Los issues se actualizan mediante /doc-review al auditar cambios en el código fuente.