Reflasheo de unidades HBOX — solo en taller

Para: Alan y Daniel (ejecución) · ingeniería (generación del binario) Versión: 1.0 · 18-sep-2026 · Responsable: Leo Rodríguez

1. Cuándo se reflashea y cuándo no

Reflashear es una prueba diagnóstica, no una reparación: sirve para contestar «¿el problema desaparece con firmware nuevo?». Si la unidad tiene un corto, un conector roto o una batería hinchada, el firmware no va a arreglar nada.

!!! danger "Dos reglas que no se rompen" 1 · Solo en taller, nunca sobre la máquina. Un flasheo interrumpido deja la unidad muerta. Si eso pasa en la mesa, se vuelve a intentar; si pasa arriba de un RTG, hay que bajarla otra vez.

**2 · Primero la evidencia, después el flasheo.** El flasheo borra la memoria del equipo
(temperatura máxima, recuperaciones, causa del último arranque) y sustituye el firmware que
estaba fallando. **Haz y sube las capturas del diagnóstico antes de tocar el botón.** El acta de
banco bloquea este paso hasta que el archivo de captura esté subido.

Situación	¿Reflashear?
Ya hiciste el diagnóstico y las capturas están subidas	Sí
La unidad tiene corto, humedad o daño visible	No — enviar a Querétaro
No sabes qué firmware trae	Primero anótalo (línea `BOOT` de la captura)
La unidad está instalada en la máquina	No. Se desmonta primero
No encuentras el `.bin` correcto en Descargas	No inventes: pregunta a ingeniería

2. Qué binario le toca a cada unidad

Los binarios viven en Descargas, con su versión y su SHA256. Cada generación de tarjeta tiene el suyo y no son intercambiables: la polaridad del control de carga está invertida entre generaciones, así que un binario equivocado puede dejar la batería cargando cuando debería estar cortada.

Generación de tarjeta	Binario	Estado
V3 (flota desplegada: RTK-003, RTK-006, RTK-014)	`hbox-fw-v3_*.bin`	⬜ pendiente de publicar
V4	`hbox-fw-v4_*.bin`	⬜ pendiente de publicar
V5 (EinarBoard v5, banco)	`hbox-v5-bringup_0.4.0.bin`	✅ publicado

Si el renglón dice pendiente, no hay binario aprobado todavía: el flasheo de esa generación está detenido hasta que ingeniería lo publique (§6).

3. Qué necesitas

Laptop con STM32CubeProgrammer (o dfu-util).
Cable USB con datos (muchos cables de carga no llevan datos — si la laptop no ve nada, prueba otro).
El .bin descargado del sitio, con su SHA256 verificado.
La unidad en la mesa, energizada solo por el USB.

Verifica el archivo antes de flashear:

# macOS / Linux
shasum -a 256 hbox-fw-v3_X.Y.Z.bin
# Windows (PowerShell)
Get-FileHash .\hbox-fw-v3_X.Y.Z.bin -Algorithm SHA256

Debe coincidir carácter por carácter con el que publica SHA256SUMS.txt. Si no coincide, descárgalo otra vez; si sigue sin coincidir, no lo uses y avisa.

4. El flasheo, paso a paso

Anota el firmware que traía. De la captura del diagnóstico, la línea BOOT,…,fw=3.0.3,…. Va en el acta. Sin este dato el reflasheo no sirve como prueba.
Conecta el USB del Blackpill a la laptop.
Entra a modo DFU:
- Mantén presionado BOOT0.
- Presiona y suelta RESET (NRST).
- Suelta BOOT0.
- En la laptop debe aparecer «STM32 BOOTLOADER» (identificador 0483:DF11). Si no aparece: repite la secuencia; si sigue sin salir, el cable no lleva datos o el MCU no arranca.
Graba el binario en la dirección 0x08000000:
- STM32CubeProgrammer → conectar en USB/DFU → Open file → Download.
- o bien: dfu-util -a 0 -s 0x08000000:leave -D hbox-fw-v3_X.Y.Z.bin
Espera a «Download complete» y «Verify successful». Si falla a la mitad, no desconectes: repite el paso 3 y vuelve a grabar.
Presiona RESET.

5. Verificación — el flasheo no termina hasta aquí

Abre el puerto serie a 115200 baudios, con guardar a archivo.
Presiona RESET otra vez y captura el arranque.
Comprueba:

Aparece la línea BOOT con la versión nueva en fw=.
El LED vuelve a parpadear (no se queda apagado ni en parpadeo rápido permanente).
Empiezan a salir líneas TLM, cada pocos segundos.
Ningún EVT de falla repitiéndose sin parar.

Deja correr 10 minutos con antenas conectadas y vuelve a mirar: state debe llegar a RUN, y link debe salir de SRCH.
Sube esta captura al acta, junto con la de antes del flasheo. Las dos juntas son la prueba de si el firmware cambió algo.

Resultado	Qué sigue
Arranca y se estabiliza en `RUN`	Candidata a reinstalar — coordina con ICAVE
Arranca pero repite la misma falla	El firmware no era la causa → enviar a Querétaro
Ya no arranca después del flasheo	Repite DFU con otro cable; si sigue, enviar a Querétaro

6. Para ingeniería — cómo se genera el binario

(Esta sección no es para el técnico: es para quien publica el .bin.)

Hoy el repositorio no contiene binarios compilados de V3 ni de V4 — solo el de bring-up del V5, que sí está publicado y versionado. Los .bin de firmware están en .gitignore a propósito. Para que el procedimiento de arriba funcione, cada generación necesita un binario compilado, probado en banco y publicado con su SHA256.

Fuentes: 04-Source-Code/firmware/blackpillrtkcode_v3/ y …_v4/.

Compilación reproducible con arduino-cli (verifica el FQBN contra tu instalación del core STM32duino antes de darlo por bueno):

arduino-cli core install STMicroelectronics:stm32
arduino-cli compile \
  --fqbn STMicroelectronics:stm32:GenF4:pnum=BLACKPILL_F411CE \
  --build-property "compiler.cpp.extra_flags=-DTARGET_EINARBOARD=1" \
  --output-dir release/ \
  blackpillrtkcode_v3/
shasum -a 256 release/*.bin >> release/SHA256SUMS

!!! warning "El flag de destino de tarjeta no es cosmético" TARGET_EINARBOARD y TARGET_PROTO invierten la polaridad del control de carga (en producción CHRG_EN en alto = carga apagada; en protoboard CHRG_RUN en alto = carga encendida). Compilar con el destino equivocado puede dejar la batería cargando justo cuando el firmware cree que la está protegiendo por temperatura — precisamente la falla #1 del RCA.

Antes de publicar:

Compilado con el TARGET_ correcto para la generación de tarjeta.
Probado en banco en una unidad real, no solo compilado.
Verificada la polaridad del control de carga sobre hardware.
Publicado en docs/descargas/ con versión en el nombre y su línea en SHA256SUMS.txt.
Anotado en el CHANGELOG.md del repositorio de firmware, con la fecha.
Actualizada la tabla de §2 de este documento.

6.8 KiB Raw Blame History