--- title: "Reflasheo de unidades HBOX — solo en taller" tags: [project-drogheda, hbox, procedimiento, reflasheo, firmware, dfu, v3, v4, v5] date: 2026-09-18 project: Project Drogheda author: Helgen Technologies version: 1.3 --- # 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](diagnostico-banco.md), 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](../descargas/index.md) con SHA-256 verificado, unidad en la mesa alimentada solo por USB, [acta de reflasheo](../formularios/reflasheo.html). 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](../descargas/index.md#firmware-del-hbox-que-binario-va-en-que-tarjeta)). 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 1. 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. 2. Verifica el SHA-256 del `.bin` ([cómo](../descargas/index.md#verifica-el-sha-256)). 3. USB del Blackpill (o J11 en V5) a la laptop. 4. 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. 5. Graba en `0x08000000`: STM32CubeProgrammer (USB/DFU → Open file → Download) o `dfu-util -a 0 -s 0x08000000:leave -D hbox-tarjetaV3_X.Y.Z.bin`. 6. Espera "Download complete" y "Verify successful". Si falla a la mitad, no desconectes: repite 4 y 5. 7. Pulsa RESET. ## 3. Verificación 1. Puerto serie a 115200 grabando a archivo; pulsa RESET y captura el arranque. 2. 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. 3. Deja correr 10 min con antenas: `state` llega a `RUN` y `link` sale de `SRCH`. 4. Sube esta captura al [acta de reflasheo](../formularios/reflasheo.html) 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](v5-prueba-y-flasheo.md#5-flasheo-por-usb-dfu-j11-5-min)). V4: solo con USB, sin 24 V y sin batería ([procedimiento V4](v4-prueba-fw-0.5.6.md)). ## 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 `` y ``: basta el core STM32. Compilación con `arduino-cli` (verifica el FQBN contra tu core STM32duino): ```bash # 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.1.bin shasum -a 256 release/hbox-tarjetaV4_0.6.1.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](../descargas/index.md): - [ ] 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`) con su línea en el `MAP` de `scripts/sync-docs.sh`; la versión anterior pasa a `superseded/` en el `MAP` y con `mv` (el script no borra). `SHA256SUMS.txt` lo regenera `sync-docs.sh`. - [ ] [Notas de versión](../descargas/notas-de-version.md): qué cambia respecto a la versión anterior y por qué. - [ ] 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í. | | 1.3 | 2026-09-29 | Ejemplo con 0.6.1; publicar incluye el `MAP` de `sync-docs.sh`, mover la versión anterior a `superseded/` y las notas de versión. | Versiones anteriores en git.