Reflasheo de unidades HBOX — solo en taller

!!! abstract "Para quién · Cuándo · Tiempo · Necesitas" - Para quién: técnicos de taller (Alan y Daniel); §5 es para ingeniería. - Cuándo: unidad V3, V4 o V5.5 después del diagnóstico en banco, con las capturas ya subidas al acta. - Tiempo: 20 min de flasheo + 10 min de verificación. - Necesitas: laptop con STM32CubeProgrammer o dfu-util, cable USB con datos, el .bin de la tarjeta desde Descargas con SHA-256 verificado, unidad en la mesa alimentada solo por USB, acta de reflasheo.

Reflashear es una prueba diagnóstica ("¿desaparece la falla con firmware nuevo?"), no una reparación. Un corto, un conector roto o una batería hinchada no se arreglan con firmware.

!!! warning "Reglas" 1. Solo en taller, nunca sobre la máquina. Un flasheo interrumpido deja la unidad muerta; en la mesa se reintenta, arriba de un RTG hay que bajarla otra vez. 2. Primero la evidencia. El flasheo borra la memoria del equipo (temperatura máxima, recuperaciones, causa del último arranque). Sube las capturas del diagnóstico antes; el acta de banco bloquea este paso hasta que estén. 3. Un binario por tarjeta (tabla y reglas en Descargas). Si no encuentras el .bin correcto, pregunta a ingeniería.

1. Cuándo sí y cuándo no

Situación	Reflashear
Diagnóstico hecho y capturas subidas	Sí
Corto, humedad o daño visible	No: a Querétaro
No sabes qué firmware trae	Primero anótalo (línea `BOOT` de la captura)
Unidad instalada en la máquina	No: se desmonta primero
El binario de esa tarjeta dice "pendiente" en Descargas	No: flasheo detenido hasta que ingeniería lo publique (§5)

2. Flasheo

Anota el firmware que traía (línea BOOT,…,fw=3.0.3,… de la captura) en el acta. Sin ese dato el reflasheo no sirve como prueba.
Verifica el SHA-256 del .bin (cómo).
USB del Blackpill (o J11 en V5) a la laptop.
Modo DFU: mantén BOOT0, pulsa y suelta RESET (NRST), suelta BOOT0. Debe aparecer STM32 BOOTLOADER (0483:DF11). Si no, repite; si sigue sin salir, cambia el cable (muchos son solo de carga) o el MCU no arranca.
Graba en 0x08000000: STM32CubeProgrammer (USB/DFU → Open file → Download) o dfu-util -a 0 -s 0x08000000:leave -D hbox-tarjetaV3_X.Y.Z.bin.
Espera "Download complete" y "Verify successful". Si falla a la mitad, no desconectes: repite 4 y 5.
Pulsa RESET.

3. Verificación

Puerto serie a 115200 grabando a archivo; pulsa RESET y captura el arranque.
Comprueba:
- Línea BOOT con la versión nueva en fw=.
- El LED parpadea (no apagado ni en parpadeo rápido permanente).
- Salen líneas TLM, cada pocos segundos.
- Ningún EVT de falla repitiéndose.
Deja correr 10 min con antenas: state llega a RUN y link sale de SRCH.
Sube esta captura al acta de reflasheo junto con la de antes.

Resultado	Siguiente
Arranca y queda en `RUN`	Candidata a reinstalar; coordina con ICAVE
Repite la misma falla	El firmware no era la causa: a Querétaro
Ya no arranca	Repite DFU con otro cable; si sigue, a Querétaro

4. V5 y V4

Mismo DFU. V5: por J11 (flasheo V5 §5). V4: solo con USB, sin 24 V y sin batería (procedimiento V4).

5. Para ingeniería — generar y publicar un binario

El repositorio no contiene binarios compilados de V3 ni V4 (.bin en .gitignore).

Tarjeta	Código fuente	Falta
V3	`04-Source-Code/firmware/blackpillrtkcode_v4/` (4.0.0): lógica de v3.0.3 + telemetría en banda	Prueba de banco (RTK-003 / RTK-006)
V4	`hbox_v5_bringup/` + `board_v4.h` (la V4 es la V5 en un Blackpill)	Prueba de banco

blackpillrtkcode_v3 (3.0.4) queda como referencia: es la lógica de campo sin telemetría en banda. V3 solo usa <Arduino.h> y <math.h>: basta el core STM32.

Compilación con arduino-cli (verifica el FQBN contra tu core STM32duino):

# 1. toolchain (una sola vez)
brew install arduino-cli          # o descárgalo de arduino.cc
arduino-cli config init
arduino-cli config add board_manager.additional_urls \
  https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
arduino-cli core update-index
arduino-cli core install STMicroelectronics:stm32

# 2. confirma que tu core trae la variante Blackpill (es una opcion de GenF4, no una placa aparte)
arduino-cli board details -b STMicroelectronics:stm32:GenF4 | grep -i blackpill

# 3. compila — usb=CDCgen es obligatorio: sin el, la consola USB queda muda
cd ~/Documents/Claude/Projects/Drogheda/04-Source-Code/firmware
arduino-cli compile \
  --fqbn "STMicroelectronics:stm32:GenF4:pnum=BLACKPILL_F411CE,usb=CDCgen,xserial=generic,rtlib=nanofp" \
  --output-dir release/ \
  blackpillrtkcode_v4/

# 4. nómbralo por tarjeta + versión y saca su huella
mv release/blackpillrtkcode_v4.ino.bin release/hbox-tarjetaV3_4.0.0.bin
shasum -a 256 release/hbox-tarjetaV3_4.0.0.bin | tee -a release/SHA256SUMS

# 5. V4: mismo codigo que V5, compilado para Blackpill con board_v4.h
arduino-cli compile \
  --fqbn "STMicroelectronics:stm32:GenF4:pnum=BLACKPILL_F411CE,usb=CDCgen,xserial=generic,rtlib=nanofp" \
  --build-property "build.extra_flags=-DHBOX_BOARD_V4" \
  --output-dir release/ hbox_v5_bringup/
mv release/hbox_v5_bringup.ino.bin release/hbox-tarjetaV4_0.6.0.bin
shasum -a 256 release/hbox-tarjetaV4_0.6.0.bin | tee -a release/SHA256SUMS

El .ino trae por omisión TARGET_EINARBOARD 1 y TARGET_PROTO 0, correcto para la flota (EinarBoard 1.0 con v2/v3, según V4-PLAN.md). Solo se cambia, editando el .ino, para una tarjeta de protoboard.

!!! warning "El destino de tarjeta invierte la polaridad del cargador" Producción: CHRG_EN alto = carga apagada. Protoboard: CHRG_RUN alto = carga encendida. Con el destino equivocado la batería puede quedar cargando cuando el firmware cree protegerla por temperatura (falla #1 del RCA de junio).

Antes de publicar en Descargas:

Compilado con el TARGET_ correcto para la tarjeta.
Probado en banco en hardware real, no solo compilado.
Polaridad del control de carga verificada sobre la tarjeta.
Nombre con tarjeta y versión (hbox-tarjetaV3_X.Y.Z.bin); nunca se infiere una de la otra.
Copiado a docs/descargas/ de hbox-docs (los .bin de campo están en .gitignore); SHA256SUMS.txt lo regenera sync-docs.sh.
Anotado en el CHANGELOG.md del firmware con fecha y quién lo probó.
Tabla de Descargas actualizada; publicado con ./scripts/deploy.sh.

Historial de revisiones

Versión	Fecha	Cambios
1.0	2026-09-18	Primera versión.
1.1	2026-09-29	Encabezado uniforme; enlaces a manuales y al acta.
1.2	2026-09-29	Edición breve. Tabla de binarios y verificación SHA-256 → Descargas; la lista "antes de publicar" vive solo aquí.

Versiones anteriores en git.

7.4 KiB Raw Blame History