137 lines
7.8 KiB
Markdown
137 lines
7.8 KiB
Markdown
---
|
|
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 `<Arduino.h>` y `<math.h>`: 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.
|