hbox-docs/docs/hardware/firmware-auditoria-29oct.md

title	tags	date	project	author	version	status	audience
Firmware 0.7.0: auditoría para V5.6/V5.7 y compatibilidad con la v6 (29-oct)	project-drogheda firmware auditoria v5.6 v5.7 v6 stm32f411 stop rtc sc16is752 lis2dh12 w5500 fota	2026-10-29	Project Drogheda	Helgen Technologies (auditoría: tres revisiones independientes de Claude; integración: Claude; para: Leo)	1.0	Publicado con 0.7.0-pre2 (solo banco)	ingeniería

Firmware 0.7.0: auditoría para V5.6/V5.7 y compatibilidad con la v6

!!! abstract "En una línea" 0.7.0-pre2 sirve para el banco del piloto de la V5.6 y la V5.7 (un solo binario). Las tres revisiones no encontraron bloqueantes para el banco; el único bloqueante para campo (A-01) y 32 hallazgos más quedaron corregidos, y lo que falta se decide con mediciones del banco. La v6 no puede correr este binario: reutiliza ≈ 85 % del código pero necesita un enlace nuevo en el MCU (≈ 46 días-ingeniero) y dos decisiones de Leo (D-29-1 y D-29-2).

1. Qué se pidió y cómo se revisó

Leo (29-oct, 08:11): auditar a fondo el firmware 0.7.0, que debe servir para la V5.6 y la V5.7 y, ojalá, para la v6. Tres revisiones, cada una por un agente que no escribió el código que revisaba:

Revisión	Qué	Contra qué
A	El 0.7.0-pre publicado el 27-oct (hbox-firmware 001d3d2) en la V5.6 y la V5.7, completo	Los netlists de la V5.6 y la V5.7 (pin por pin), las hojas de datos, el core de STM32duino 3.0.0, los invariantes del proyecto y escenarios adversos nuevos en el simulador
B	El 0.7.0 en la v6: qué corre, qué falta y cómo llegar a un solo código	El netlist de la v6 del 28-oct (después de T48, T49 y T41) y un board_v6.h de borrador compilado en la Mac
C	Lo nuevo de 0.7.0-pre2 (ciclo de batería con STOP + RTC, driver del SC16IS752, acelerómetro, W5500 en power-down, robustez), que A no vio	Manual de referencia del STM32F411 (RM0383), HAL, hojas de datos del SC16IS752, LIS2DH12 y W5500, y el simulador

Mientras A y B trabajaban, Claude escribió las piezas que faltaban para el banco del piloto (F-2, F-3, F-5, E-3) y una revisión propia de robustez; C revisó ese código.

2. Resultado

Pregunta	Respuesta
¿El 0.7.0 sirve en la V5.6 y la V5.7?	Sí, el mismo binario en las dos (los 64 pines del MCU son iguales; solo cambia la entrada de energía). Banco sí; campo no hasta que el piloto pase sus 8 criterios y se cierre A-02
¿Hubo bloqueantes?	Uno para campo: A-01, un reloj que a los 24.86 días convertía a un módem sano en «oscuro» y lo reiniciaba cada 0.6 s. Corregido. Ninguno para el banco
¿Qué se corrigió?	33 hallazgos: 17 de los 23 de la revisión A (§3) y 16 de los 19 de la revisión C (§4), entre ellos los dos de severidad alta de la C (el STOP con la USB desconectada y el acelerómetro que no se reconfiguraba)
¿Qué queda?	A-02 (vida del módem con el caster caído) y la A/B del W5500 se deciden con mediciones del banco; A-09, A-13/A-14, A-20 y A-21 tienen dueño (§6). La flash del RCT6 va al 97–98 %
¿Y la v6?	El binario de la V5.6 no corre en la v6 (PC3, PC10, F9P a 38 400, EFCR 0x10). Se reutiliza ≈ 85 % del código; faltan 45–60 KB de enlace propio (A7670, NTRIP, UDP, F9P desnudo, aprovisionamiento, FOTA): ≈ 39–53 días-ingeniero. Un solo código, dos binarios (§5)
¿Qué tiene que decidir Leo?	D-29-1 (seis cambios de hardware de la v6 antes de G1) y D-29-2 (ruta del RTCM, contrato con htracker, ID de tarjeta, secretos, banco de evaluación y la fecha de G2)

3. La V5.6 y la V5.7 (revisión A, sobre 0.7.0-pre)

Veredicto: banco SÍ, con condiciones; campo NO hasta cerrar la lista de abajo. No hay ningún bloqueante eléctrico para el banco: el arranque seguro es correcto, las reglas de la etapa, el módem y K1 se cumplen en cada escritura de pin, el analizador de RTCM rechaza la basura, el gobernador de carga corta en una vuelta del lazo y ningún camino bloqueante se acerca al watchdog. Los binarios publicados el 27-oct se reconstruyen byte por byte en la Mac con el mismo SOURCE_DATE_EPOCH. Los 14 arreglos de la revisión del 27-oct están en el código (dos incompletos: A-01 y A-02). Sin credenciales en las fuentes ni en los binarios.

Los 64 pines del MCU son idénticos en la V5.6 y la V5.7 (netlist, pin por pin) y cada red coincide con board_v56.h; las direcciones I²C coinciden con los straps. Lo único distinto entre las dos tarjetas es la entrada de energía (J16 externo en la V5.6, U15 TPS54360B en la V5.7): el mismo binario sirve.

3.1 Hallazgos y cómo quedaron en 0.7.0-pre2

ID	Severidad	Qué pasaba	En 0.7.0-pre2
A-01	Bloqueante para campo	A los 24.86 días de encendido, un flanco del LED o una trama RTCM viejos ganaban las comparaciones con signo y contaban como la evidencia más nueva: OSCURO falso, pulsos de RESET cada 0.6 s, 91 174 $PHEV y cero $PHLG en 20 min (simulador). La unidad desaparecía	✅ La evidencia de más de 1 día se olvida. Los 4 escenarios del volteo pasan
A-02	Alta	Con el caster caído, un módem sano sin LED visible (1.8 V contra un VIH de 1.79–2.31 V) o con el LED fijo recibe pulsos y reinicios de alimentación: 20 pulsos y 4 reinicios en 2 h	⏳ Abierto. El banco caracteriza el LED en cada estado (§7.6) y con eso se decide (leer PC2 por ADC, o no escalar cuando solo falta el RTCM). Mientras: caster de Helgen y anotar rst=/pwrcyc=
A-03	Alta	Sin los TMP102 la protección térmica se abría (−99 = «frío»): tras un corte a 78 °C la etapa se rearmaba a ciegas. El SHT40 muerto se quedaba con su último valor; sin recuperación del bus en marcha	✅ Protección con el sensor del MCU, sin rearme si faltan U12 y U8 (TEMP_NOREARM), recuperación del bus I²C en marcha, SHT40 en n/c y con CRC
A-04	Alta	Un reset (IWDG, BOR, botón) en batería dejaba la unidad muda hasta que volvía el 24 V	✅ El ciclo de batería vuelve a abrir la ventana; desde el tercer reset seguido espera 10 min (nunca un lazo)
A-05	Media	«5 V presente» (4.20/3.80 V) quedaba debajo del PFI del LTC4040 (4.40/4.51 V): entre 3.8 y 4.4 V la tarjeta corría del paquete sin respaldo ni SLEEP	✅ Presente > 4.60 V, perdido < 4.45 V (en el archivo de la tarjeta)
A-06	Media (banco)	-eth: tras un corte de 24 V o la tecla E, el W5500 se colgaba en SPI hasta el watchdog	✅ SPI.begin() antes de cada init
A-07	Media	Con las banderas de flash solo en C++, el binario enlazaba con la EEPROM en 0x0807E000 (no existe en el RCT6): se caía al arrancar	✅ flash_guard.c: así ya no enlaza (probado en la Mac)
A-08	Media	Cristal de 25 MHz muerto = while(1) antes del watchdog	✅ Arranca con el HSI a 96 MHz (CSS queda pendiente: con el HSI y el IWDG basta para el banco)
A-09	Media	El BOR nunca se programa (de fábrica: apagado)	ℹ️ La autoprueba lo informa; programarlo en nivel 3 es un paso de fábrica (pendiente de decidir dónde)
A-10	Media	A guardaba MANUAL en flash con una tecla (sobrevive un reflasheo); los bloqueos del operador no vencían	✅ A pide Y; modo=MAN en $PHEV BOOT; los bloqueos vencen a las 2 h sin USB; §11 revisa modo=AUTO
A-11	Baja	$PHLG en banda sin tope: 106–107 caracteres en una unidad estresada	✅ Contadores con tope y segunda pasada si pasa de 105
A-12	Baja	g e i bloqueaban con K1 puesto (se perdían bytes del F9P al módem)	✅ Sueltan K1 antes
A-13 / A-14	Baja (hardware)	Base de Q3 sin pull-down mientras PA1 está en alta impedancia; el cargador queda encendido por defecto si el MCU no corre	📝 Para la siguiente revisión de la tarjeta
A-15	Info	En batería el ventilador no tiene alimentación, pero el log decía «termostato»	✅ En batería se apaga y lo dice
A-16 / A-17	Info / Baja	Orden de lectura de dos bytes sin especificar; CRC del SHT40 ignorado	✅ Lecturas en orden; CRC revisado
A-18	Baja	El binario solo se reproduce con el mismo SOURCE_DATE_EPOCH	✅ Se publica con el valor anotado en el CHANGELOG
A-19	Baja	Tres de las «18 PASS» no podían fallar y la prueba del módem apagado no era veredicto	✅ ADC con rangos y MODEM_APAGADO son veredictos
A-20	Baja	$PHEV sin límite por código	⏳ Se coordina con el servidor (Gibran): el monitor usa pares de eventos
A-21	Baja (sin verificar)	El reinicio de 5 s del módem supone que 3V3_MODEM baja al nivel de reset	⏳ Osciloscopio en J8.1 con Q (§7.8)
A-22	Info	En SLEEP el MCU seguía a 96 MHz	✅ Con el ciclo de 0.7.0-pre2, en SLEEP también hay STOP
A-23	Info	Comentarios del LSE, de la vida del módem y de PC2 desactualizados	✅ Al día

3.2 Condiciones para el banco (ya están en el procedimiento 1.2)

1. El build -eth solo para las 24 h de Ethernet; al final, un corte de 24 V de 30 s debe pasar sin reinicio (confirma A-06 en hardware). El criterio 4 (20 cortes) siempre con el binario sin -eth.
2. Caster de Helgen, no rtk2go; rst= y pwrcyc= al final de cada prueba (A-02).
3. §7.6: osciloscopio en J9.8 y PC2 en cada estado del módem (decide A-02).
4. §7.8: osciloscopio en J8.1 con Q (A-21).
5. Pruebas térmicas siempre con alguien presente.
6. §11: modo=AUTO antes de guardar la tarjeta (A-10).

3.3 Espacio en flash

En el RCT6 el binario no puede pasar de 128 KB (la EEPROM emulada ocupa el sector 5). El Ethernet de campo (F-4) cuesta ≈ 17 KB: con todo lo demás no cabe en la misma imagen del RCT6. Para recuperar espacio, en orden: mover la EEPROM emulada a un sector de 16 KB (libera hasta ≈ 240 KB), quitar el printf de punto flotante (≈ 10 KB) y dejar la ayuda y la leyenda fuera de los builds de campo (≈ 17 KB de texto). El FOTA A/B no cabe en el RCT6 en ningún arreglo: necesita el RET6 (D-22-6, ya decidido).

4. Lo nuevo de 0.7.0-pre2 (revisión C)

Veredicto: sin bloqueantes; apto para un banco supervisado con los dos arreglos que pidió y que ya están en el código: el STOP con la USB desconectada (H1) y el procedimiento 1.2 (M4). El código nuevo no pone en riesgo el hardware y mantiene al watchdog alimentado: en un modelo donde el SysTick se detiene en STOP, la recarga más espaciada del IWDG es de 5.0 s. La mecánica del STOP con el RTC es correcta: los despertares caen a los 900, 1500 y 2100 s, millis() se desvía menos de 0.1 s en unas 400 siestas y el 5 V que vuelve se ve en ≤ 5 s. El enlace del bloque STOP/RTC y del respaldo con HSI se comprobó con el core 3.0.0 en la Mac.

4.1 Qué trae 0.7.0-pre2 para el banco del piloto

Pieza	Qué hace	Criterio
F-2 · ciclo de batería	Al perder el 5 V la ventana en curso sigue y cierra con ≥ 120 s, fix y 2 $PHLG después de la primera RTCM (el enlace probado); sin RTCM, a los 180 s. Luego todo apagado en orden y el MCU en STOP: despierta cada 5 s y a los 10 min del inicio de la ventana anterior. Un episodio de movimiento abre una ventana a los 5 min de la anterior (o ya). Con la USB conectada no hay STOP	3
F-3 · puertos serie	Driver del SC16IS752; tecla S (RS-232 con un puente en J12 y RS-485 contra otra tarjeta en eco, U); autoprueba SER_B_LAZO con el tiempo del cristal Y3	5
F-5 · acelerómetro	LIS2DH12 a 10 Hz, movimiento por INT1, $PHEV MOTION en banda sin 5 V o sin ignición; autoprueba ACCEL_1G	—
E-3 · W5500	Fuera del build -eth, el PHY en power-down, verificado cada minuto; tecla W para comparar con el reset	3
Robustez	Y2 muerto → HSI; bus I²C colgado → se libera solo; sin TMP102 → sensor del MCU y sin rearme térmico; imagen que invade el sector 5 → aviso y A no escribe	—

4.2 Hallazgos y cómo quedaron

ID	Severidad	Qué pasaba	En 0.7.0-pre2
H1	Alta	El STOP dependía de CON.dtr(). En el core 3.0.0 solo lo escribe SET_CONTROL_LINE_STATE y no hay detección de VBUS: al desconectar el cable se queda en 1. Siguiendo la propia ayuda («el piso se mide sin USB») nunca había STOP y el criterio 3 habría medido un MCU despierto. Con la USB conectada y la terminal cerrada, el STOP tumbaba el USB	✅ Decide el estado del dispositivo USB: CONFIGURED = sin STOP; desconectado (SUSPENDED) = STOP. Compila y enlaza con el core 3.0.0
H2	Alta	Si el bus seguía caído en la única recuperación, el LIS2DH12 quedaba sin configurar para siempre; el primer movimiento enclavaba INT1 y bloqueaba el STOP hasta reiniciar	✅ Reintento cada 5 s; sin driver, accIrq nunca se queda arriba
M1	Media	Sin U12/U8 (o dañados) «bus caído» se cumplía siempre: una recuperación por minuto para siempre, U5 despertado y el divisor escrito en sleep, y I2C_RECOVER llenando la cola en banda	✅ «Bus caído» exige que callen también el PCF8574 y U5; I2C_RECOVER en banda máx. 1 por hora; EFCR_A revisado cada minuto
M2	Media	U5 solo se dormía al cerrar una ventana: no tras un corte por SLEEP, por temperatura ni al arrancar en batería (justo el caso del paquete bajo)	✅ Se duerme en todo reposo, con la FIFO de RX vaciada antes
M3	Media	Una vez en power-down, el W5500 no se volvía a revisar: si /3V3_ETH caía y volvía, regresaba en autonegociación (~75 mA) sin que nadie lo notara	✅ Verificación cada 60 s; si no cuadra, reset y power-down otra vez
M4	Media	El procedimiento seguía en 0.7.0-pre	✅ Procedimiento 1.2 y actas
M5	Media	SER_B_LAZO pasaba con cualquier cristal que oscilara y decía «3.6864 MHz»	✅ 32 bytes a 9600 medidos contra el reloj del MCU: 33.3 ms (PASS con 30–38 ms)
L1	Baja	Un episodio de movimiento que empezaba antes de los 5 min de la ventana anterior se perdía	✅ Queda pendiente: la ventana abre a los 5 min de la anterior
L2 / L3	Baja	Sin una línea que sense /3V3_ETH, el firmware le maneja pines a un W5500 sin alimentación al probarlo; y no se sabe si gasta menos en reset o en power-down	⏳ Acotado: tras 3 intentos sin respuesta, uno por hora. La tecla W deja a U2 en reset para medir los dos pisos con el PPK2; el menor decide
L4	Baja	El divisor se escribía con U5 en sleep (la hoja de datos lo prohíbe)	✅ Primero se despierta
L5	Baja	El canal B quedaba a 115 200 tras la autoprueba	✅ A 9600
L6	Baja	Si Y2 no rearrancaba al salir de un STOP, nadie lo decía	✅ $PHEV CLOCK hse_fail_stop
L7	Baja	Con el LSI el texto prometía ±10 %; la hoja de datos da 17–47 kHz	✅ Texto corregido (siestas de 3.4–9.4 s, ciclo de ~7–19 min). Con el LSE sano no aplica: un Y4 que no arranca es FALLA en la autoprueba
L8	Baja	Con el option byte nRST_STOP en 0 cada STOP sería un reset	✅ Sin STOP en ese caso
L9	Baja	El eco de banco (U) pasaba a la batería con U5 despierto	✅ Se apaga al entrar en batería
L10	Baja	Al cerrar una ventana, MODEM_EN y PA1 bajaban a microsegundos uno del otro	✅ 20 ms entre los dos, como en el reset por software
L11	Baja	El bus se daba por libre con SDA arriba aunque SCL siguiera abajo	✅ Se revisan los dos
L12	Info	La ventana de 180 s es igual al tiempo sin vida del módem: en batería nunca pasa del primer pulso	ℹ️ Por diseño: cada ventana es un arranque en frío del módem. Para la revisión del módem

4.3 Lo que solo dice el banco

El simulador no tiene modelo de corriente ni de USB. En el banco se mide: el piso con el PPK2 (W5500 en power-down contra reset, U5 con J11 al aire contra terminado, el MCU en STOP), el primer STOP en silicio, qué pasa al conectar la USB en reposo (la consola debe aparecer al terminar la siesta, ≤ 5 s) y un Y3 de valor equivocado. Todo está en el §10.1 del procedimiento 1.2.

5. La v6: qué del 0.7.0 sirve y qué falta

Revisión independiente (agente B, 29-oct) contra el netlist de la v6 del 28-oct (después de T48, T49 y T41), con los pines leídos del netlist y no de los documentos. Compiló el 0.7.0 y un board_v6.h de borrador en la Mac.

5.1 Veredicto

El binario de la V5.6/V5.7 no corre en la v6, y la mitad del firmware que hace de la v6 un producto todavía no existe.

En una v6, el 0.7.0 de hoy:

• nunca enciende el módem: en la v6 el enable es PC10 y el 0.7.0 no lo toca;
• maneja PC3 como MODEM_EN, pero en la v6 PC3 es la salida push-pull RTK_STAT del F9P: lo sostiene en bajo contra el alto del F9P los primeros 30 s de cada encendido del GNSS y 5 s dos veces por escalera;
• abre el F9P a 115 200 cuando un F9P de fábrica habla a 38 400: no ve NMEA, cicla el riel del GNSS 3 veces en ≈ 15 min y queda en LIMP;
• escribe EFCR = 0x30 lo primero, y el inversor U11 de la v6 lo convierte en «transmisor RS-485 encendido en reposo»: toma el bus (en la v6 el valor correcto es 0x10).

Una unidad así nunca reporta y castiga a PC3. Hay que evitar que un técnico flashee el binario de la V5.6 en una v6 (abajo, cambios de hardware 2).

5.2 Cuánto se reutiliza

Cerca del 85 % del código (≈ 57 de ≈ 67 KB): gobernador de carga, umbrales LFP, NTC del paquete, ADC calibrado con VREFINT, política térmica y de respaldo, el analizador de NMEA, $PHLG/$PHCG/$PHEV y su cola, la consola y la autoprueba, los sensores I²C, el código del W5500, el IWDG, el motivo de reset en BKP16–19 y el simulador. Una cuarta parte de eso necesita constantes o pines de la tarjeta. Lo que solo existe en la V5.x (≈ 15 %: el modo B con K1, la inyección en banda, PHTST, la vida por el LED) se queda fuera del build de la v6.

Lo que trae 0.7.0-pre2 también sirve en la v6, con los valores de su archivo de tarjeta: el driver del SC16IS752 con SC16IS_EFCR_RS485 = 0x10, el acelerómetro con ACC_WHOAMI = 0x11 (SC7A20; el driver de movimiento falta para ese chip) y el STOP + RTC del ciclo de batería.

5.3 Lo que la v6 necesita y no existe

Todo lo que hoy hacen solos los dos módulos de ArduSimple:

Pieza	Qué es
Módem A7670SA	Encendido (PC10, PWRKEY en PC8, STATUS en PC9, RESET en PC11), driver AT, SIM, registro y PDP
NTRIP	Cliente NTRIP, entrega de RTCM al F9P, GGA al caster
Enlace al servidor	NMEA y $PHLG por UDP a htracker, con la línea de identidad que hoy pone el módem ($GPTXT … H00xx)
F9P desnudo	Configuración y persistencia del ZED-F9P (de fábrica a 38 400)
Aprovisionamiento	SIM, APN, usuario NTRIP y estación: un registro de configuración por unidad, escrito en la fábrica
FOTA	Por el módem (D-22-6)

Son 45–60 KB de código nuevo y ninguno existe (documento de diseño de la v6, §13.4). El código que se reutiliza será cerca de la mitad de la imagen final.

5.4 Una sola línea de firmware

Un solo código, nunca un solo binario. Módulos compartidos, archivos de tarjeta con banderas de capacidad y dos «backends» de enlace (ArduSimple/K1 para la V5.x, A7670 para la v6). Salen hbox-tarjetaV56_x.y.z.bin y hbox-tarjetaV6_x.y.z.bin. Una revisión de la tarjeta al arrancar y el ID de tarjeta en el manifiesto del FOTA impiden que una imagen equivocada maneje los pines.

5.5 Plan y esfuerzo

Paquete	Contenido	Días-ingeniero
WP0	Decisiones (abajo)	0.5
WP1	Separar el 0.7.0 en módulos + archivos de tarjeta, sin cambiar el comportamiento en la V5.x (los escenarios del simulador en verde)	3–4
WP2	board_v6.h, arranque seguro, revisión de la tarjeta, reglas de pines de la v6, autoprueba	1.5–2
WP3	UART con DMA (USART2/6/1)	1.5–2
WP4	Motor UBX y configuración del F9P	3–4
WP5	A7670: encendido, motor AT, SIM/registro/PDP, escalera	5–6
WP6	Cliente NTRIP, reenvío de RTCM, GGA, estadísticas	3–4
WP7	Enlace UDP compatible con lo de hoy + identidad (con Gibran en htracker)	2–3 (+1–2)
WP8	Invariantes de la v6: escaleras, guarda contra lazos de arranque, PFO, modo batería, térmicos	3–4
WP9	Aprovisionamiento y registro de configuración (nunca en la imagen)	1.5–2
WP10	Simulador de la v6: A7670 por AT, caster, F9P por UBX, servidor UDP, invariantes de la v6, ≈ 35 escenarios	5–7
WP11	Puertos, sensores y Ethernet de la v6 (EFCR 0x10, SC7A20, PD2)	2–3
WP12	FOTA de la v6 sobre el cargador compartido (F1)	2–3 (+ F1 y F4 compartidos, 7–9)
WP13	Arranque y banco de la v6 (rieles, aislamiento, desensibilización del GNSS, 24 h de NTRIP, batería, térmico)	5–7
WP14	u-center y AT por la USB	1
Total de la v6		≈ 39–53 (centro ≈ 46)

Cerca del 60 % es código (Claude lo comprime); el 40 % es banco (no se comprime).

Hito	Fecha	Qué
M0	6-nov	WP0–WP2, esqueleto del simulador, piezas de banco en mano
M1 · MVP en banco de evaluación	≈ 20-nov	F9P de fábrica configurado por el MCU, A7670 en línea, NTRIP → RTK ≥ 4, NMEA + $PHLG en htracker con identidad, escalera básica, 24 h
M2 · arranque de la v6	desde ≈ 23-nov	Las 20 tarjetas del pedido del 2-nov
M3 · candidato de campo	mediados a finales de diciembre	Escaleras completas, puertos, Ethernet, aprovisionamiento, FOTA, matriz F4 en la v6

G2 tal como está escrito (≈ 22-nov, «las 20 pasan el banco») no se alcanza con firmware de campo. Propuesta: G2 = las tarjetas del piloto corriendo el MVP en banco a principios de diciembre, e imagen de fábrica con FOTA (D-22-6) a mediados o finales de diciembre.

Banco de evaluación (≈ US$100–150), para empezar antes de que existan las tarjetas: NUCLEO-F411RE (el mismo STM32F411RET6 en LQFP64: todos los pines de la v6 existen), una tarjeta de evaluación del A7670SA del mismo sufijo (-LASC), adaptadores 74LVC2T45, una nano-SIM de Vectro, un simpleRTK2B de repuesto como F9P y un punto de montaje de prueba en HelgenSRV.

5.6 Decisiones antes de escribir el enlace (para Leo)

1. Ruta del RTCM. El documento de diseño (§2/§3) lo manda por hardware (módem → U9 → U23 → RXD2 del F9P); el §13.4 y el estudio de FOTA piden un socket no transparente. En la práctica se excluyen. Recomendación: el MCU reenvía el RTCM con su CRC revisado al F9P por USART2, y las entradas del UART2 del F9P se apagan.
2. Contrato del enlace con htracker (con Gibran): UDP, los mismos formatos de línea y una línea de identidad equivalente al $GPTXT … H00xx … del módem de hoy.
3. ID de la tarjeta. Sin cambiar el BOM, la prueba de PC12 distingue V5.x de v6. Para el hardware: un divisor en PC4 (libre desde T49) que codifique la revisión. El strap de PA9 de D-v6-1 también funciona, pero solo dice «v6 sí o no».
4. Secretos por unidad (APN, usuario NTRIP, estación): en un registro de configuración del MCU escrito en la fábrica; nunca en el repositorio ni en una imagen de FOTA (invariante 6).

5.7 Cambios de hardware de la v6 que valen antes de G1 (2-nov)

#	Qué	Por qué el firmware no lo arregla	Cambio propuesto
1	La única SIM va en un portatarjetas push-push (J11, JAE SF72S006; T48 quitó la eSIM). Su detector (CSW/DSW) no está conectado	En maquinaria de puerto una SIM que se sale desaparece la unidad; el firmware solo puede notarlo (AT+CPIN?)	Retención mecánica (cinta Kapton, tapa o espuma que la presione, o un portatarjetas con bisagra o seguro) y una prueba de vibración en el banco del piloto. Opcional: CSW/DSW a un pin libre
2	Sin ID de tarjeta, y /GNSS_RTK_STAT (salida push-pull del F9P) llega directo a PC3, el pin que los builds de la V5.x manejan como MODEM_EN	El manifiesto del FOTA solo protege lo que llega por aire; el accidente probable es un flasheo DFU en el taller	(a) 1 kΩ en serie en /GNSS_RTK_STAT junto a U3.11 (limita el choque a ≈ 3.3 mA). (b) Divisor de ID en PC4 (dos resistencias 0402)
3	La corriente de entrada y de carga no se ven (CLPROG solo va a TP11)	El gobernador sigue infiriendo por la caída del riel	CLPROG → PB1 con 1 MΩ + 100 nF (era la intención original de D-10; faltó pin). CLPROG no tiene buffer interno: hay que aislarlo
4	DTR (U6.3) y RI (U6.4) del A7670 sin conectar	Sin DTR no hay AT+CSCLK=1 ni despertar por URC	DTR sin costo de BOM: el canal 2 de U5 ya traduce MCU → módem; U5.6 a PB5 (libre al quitar K1) con 100 kΩ a GND y U5.3 a U6.3. RI es opcional
5	La huella de K1 sigue en la tarjeta (DNP)	Si alguien monta K1 con R8 puesta, su contacto NC une dos salidas push-pull	Quitar K1, Q4, D3, R48 y R49 (D-v6-3)
6	/DOUT_4G flota con el módem apagado	El pull-up interno de PC7 lo cubre	Opcional: 100 kΩ a /3V3

Revisado y correcto: PWRKEY, RESET y STATUS del módem; los traductores de nivel (U5, U9, U23, con Ioff); el banco de capacitores de VBAT del módem (≈ 507 µF); el límite de corriente de la antena (TPS2552); el arranque seguro por hardware (módem, F9P, W5500 y cargador apagados); RTS/CTS sin conectar no es defecto (el A7670 no soporta control de flujo).

5.8 Errores de documentación encontrados (contra el netlist del 28-oct)

• pinmap-v6.md (v1.2): su tabla principal es la del 28-sep. Siguen mal aun con sus notas: PB1 y PC4 como NTC (sin conexión desde T49); PA9 «sin conexión» (es /USART1_TX a TP3: el USART1 vuelve a ser dúplex); PC6 y PB5 todavía con el modo B de K1 (K1, Q4, D3, R48 y R49 van DNP y R8 = 0 Ω une PC6 con /DIN_4G); PA5 con R17 de 3.3 kΩ (es 2.2 kΩ: razón 0.0833, 12 V → 1.00 V); «sin TMP102 en la v6» (U19 en 0x48 y U2 en 0x49 están montados); los pines libres son PB1 y PC4; U20 es un TPS7A2033, no un AP2112K. Su board_v6.h de borrador queda reemplazado por el del agente B.
• Documento de diseño de la v6 (v1.3): dice «GSM 900/1800»; el A7670SA es GSM de cuatro bandas 850/900/1800/1900 + LTE B1/2/3/4/5/7/8/28/66 (el GSM de México va en 850/1900). El cuerpo todavía describe las NTC externas que quitó T49. El §2/§3 y el §13.4 se contradicen sobre la ruta del RTCM (decisión 1). La rampa de VCC del F9P: el símbolo dice «≤ 20 µs/V», las notas del proyecto dicen una ventana de 20–8000 µs/V; sin verificar (la hoja de u-blox no se pudo abrir): se mide antes de fabricar.
• Estudio de FOTA: cuenta los arranques de prueba en BKP12–13, que con VBAT = /3V3 se borran en un corte completo: una imagen que tumba la tarjeta nunca se contaría. El contador va también en el sector de metadatos.
• Con los umbrales de pin de la V5.6, la ignición de la v6 diría ON a 9.6 V y OFF a 6.6 V: los umbrales van en voltios del vehículo en el archivo de cada tarjeta.

6. Lo que queda abierto

#	Qué	Quién / cuándo
A-02	Con el caster caído, un módem sano con el LED invisible o fijo todavía recibe pulsos y reinicios	Banco del piloto: §7.6 caracteriza el LED; luego se decide en el firmware de campo. Mientras: caster de Helgen y anotar rst=/pwrcyc=
L2/L3	W5500: reset o power-down en el reposo	Banco del piloto: A/B del piso con la tecla W (§10.1.5)
A-21	Si el reinicio de 5 s baja /3V3_MODEM al nivel de reset del módem	Banco: osciloscopio en J8.1 con Q (§7.8)
A-09	El BOR nunca se programa (de fábrica: apagado)	Decidir dónde se programa en nivel 3 en el volumen (paso de fábrica)
A-13 / A-14	Base de Q3 sin pull-down; cargador encendido por defecto con el MCU sin correr	Siguiente revisión de la tarjeta
A-20	$PHEV sin límite por código	Con Gibran: el monitor usa pares de eventos
L12	Ventana de 180 s = tiempo sin vida del módem	Revisión del módem
Flash	El RCT6 va al 97 % (base) y 98 % (-eth): F-4 (Ethernet de campo) no cabe junto al ciclo de batería	Antes de F-4: mover la EEPROM emulada a un sector de 16 KB, quitar el printf de punto flotante y dejar la ayuda fuera de los builds de campo (§3.3)
v6	Decisiones D-29-1 (hardware antes de G1) y D-29-2 (plan del firmware)	Leo, en el tablero

7. Cómo se verificó

• Simulador (tools/hostsim_v5): 118 escenarios en PASS (54 de V5.5/V4 y 64 de V5.6/V5.7: 42 propios, 11 de la revisión A, 7 de la revisión C y 4 escritos después de la C), 876 comprobaciones. Cuatro abiertos se corren y se muestran sin contar: A-02 ×2 y L2/L3 ×2. Nuevo en el modelo: micros(), el cristal de U5, la alimentación del W5500, el estado del USB, el IWDG y un SysTick que se detiene en STOP.
• Compilación en la Mac (core STM32duino 3.0.0, GENERIC_F411RCTX, ventana de 128 KB): base 128 204 B y -eth 129 304 B; con SOURCE_DATE_EPOCH=1793295000 dos compilaciones limpias dan el mismo SHA-256. Los builds de la V5.5 y la V4 compilan.
• Lo que no se verificó: nada corrió todavía en una V5.6 o V5.7 real (no han llegado). El banco del piloto es la prueba.

Archivo	SHA-256
hbox-tarjetaV56_0.7.0-pre2.bin	43aeabcfdb7055c106b7702682f099fdd5b83499f28cfcfab43a2fa41b1ea6a2
hbox-tarjetaV56_0.7.0-pre2-eth.bin	051af1b2c7596c169069b030123c748ab7c2378a8b2f877453ad85f9ae3bdfca

Historial de revisiones

Versión	Fecha	Cambios
1.0	2026-10-29	Primera versión: revisiones A (0.7.0-pre en V5.6/V5.7), B (v6) y C (lo nuevo de 0.7.0-pre2), y lo que se corrigió en 0.7.0-pre2.