# Descargas

Archivos que el técnico necesita en el banco. Verificar el SHA-256 antes de flashear
(`shasum -a 256 archivo` en macOS, `sha256sum archivo` en Linux, `certutil -hashfile archivo SHA256` en Windows).

## Qué archivo va a qué cosa

Una unidad HBOX tiene **tres cerebros distintos** y cada uno se carga por su propio camino. Antes de
descargar nada, ubica cuál vas a tocar:

| Qué | Qué se le carga | Cómo | Dónde está |
|---|---|---|---|
| **Tarjeta HBOX** (Blackpill / EinarBoard) | Firmware `.bin` | DFU por USB | [§ Firmware del HBOX](#firmware-del-hbox-que-binario-va-en-que-tarjeta) |
| **Módem 4G NTRIP Master** | Archivo de **parámetros** `$$$AS+…` | Terminal serie por el USB *XBEE* | [§ Módem 4G](#parametros-del-modem-4g-ntrip-master) |
| **simpleRTK2B Pro (ZED-F9P)** | Configuración u-center **y** firmware u-blox | u-center por el USB *POWER+GPS* | [§ ZED-F9P](#firmware-y-configuracion-del-simplertk2b-pro-zed-f9p) |

Cada carga se registra en el **[acta de reflasheo](../formularios/reflasheo.html)**, y queda en el
[expediente de esa unidad](../unidad.html) junto con las capturas de antes y después.

!!! warning "Verifica el SHA-256 antes de flashear"
    Un binario incompleto o de otra generación puede dejar la tarjeta inservible.
    `shasum -a 256 archivo` (macOS) · `sha256sum archivo` (Linux) · `certutil -hashfile archivo SHA256` (Windows).

## Firmware del HBOX — qué binario va en qué tarjeta

**Regla: un binario por tarjeta.** La versión del firmware no dice nada de la tarjeta (`0.4.0` no es
"para V4": es una versión vieja del firmware de V5). El binario lleva la tarjeta en el nombre y eso es lo que manda.

| Tarjeta | MCU | Código fuente | **Binario vigente** | Estado |
|---|---|---|---|---|
| **V3** — EinarBoard 1.0, las 3 unidades en campo | Blackpill en zócalo (F411CE) | `blackpillrtkcode_v4` (4.0.0) | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) | ⚠ compilado, **sin prueba de banco** |
| **V4** — `hbox-watchdog-v4` | Blackpill en zócalo + PCF8574 · W5500 · SC16IS752 | `hbox_v5_bringup` + `board_v4.h` | [`hbox-tarjetaV4_0.5.7.bin`](hbox-tarjetaV4_0.5.7.bin) | ⚠ compilado 26-sep, **sin prueba de banco**. Despertar de batería por reset del MCU; puente U13-P7 → SW4G1 como respaldo — [preparación y prueba V4](../procedimientos/v4-prueba-fw-0.5.6.md) |
| **V5** — `hbox-watchdog-v5`, lote de 15 | STM32F411RET6 soldado | `hbox_v5_bringup` (0.5.7) | [`hbox-v5-bringup_0.5.7.bin`](hbox-v5-bringup_0.5.7.bin) | ⚠ **vigente desde 26-sep (0.5.7)** — batería: ventana de 2 min cada 10 min; **cada despertar y cada regreso del 5 V = reset del MCU** (lo único que en banco enciende el módem sin puente); tecla `R`; reset y `P` en batería; 0.5.1 fue la última en campo |

Los tres reportan al servidor **la misma trama**: `$PHLG` de 29 campos cada 30 s y un `$PHEV` por cada
cambio de estado, en banda por el módem (Modo B). Es exactamente lo que el monitor desplegado parsea hoy
(`retranslator.py`: 20 campos base + 4 de v3 + 5 de 0.5.1, y `$PHEV`), así que las tres tarjetas se ven
igual en la columna *Salud*.

!!! warning "0.5.x (V4 y V5) cambia cómo se ve la unidad en el monitor cuando está en batería"
    Desde 0.5.2 la unidad **apaga el módem entre reportes** mientras está en batería: enciende ~120–180 s cada
    10 min, manda posición y `$PHLG` con `pwr=BATT`, avisa `DUTY_SLEEP next=<s>` y se calla. Para que ese
    silencio **no aparezca como desconexión** (ni dispare el correo del notifier, ni cuente como caída), el
    `retranslator.py` del servidor debe llevar el soporte `DUTY` (24-sep). **Desplegar primero el servidor,
    después flashear 0.5.7.** Con la V3 (4.0.0) no cambia nada: sigue reportando continuo en batería.

!!! danger "0.5.7 — el módem en batería: despertar por reset del MCU, y el puente U13-P7 → SW4G1 como respaldo"
    En cada ventana de batería el módem quedaba con **todos los LEDs apagados** (no enciende). Banco 26-sep: un ciclo de
    etapa desde el firmware (`P`/`P`+`Y`, 5–60 s) **nunca** lo enciende, pero un **reset del MCU por P10 con 24 V lo
    enciende siempre**, y un pulso en **`SW4G1`** también. Por eso **0.5.7 hace en cada despertar de batería y en cada
    regreso del 5 V un reset del MCU** (arranca en ~4 s y abre la ventana de inmediato). **Prueba decisiva antes de la
    corrida en batería:** con el módem oscuro en 24 V, tecla **`R`** (reset por software): si lo revive igual que P10,
    las ventanas van a funcionar. Si `R` no lo revive, queda el puente (0.5.6+, sigue en el firmware):

    ```
    U13 pin 12 (P7)  ──|<──  SW4G1 pad 1 (MODEM_RST)     diodo Schottky de señal BAT54 (o BAT85/BAT43/1N5711) — no 1N5819
                    cátodo   ánodo
    ```

    Verificar con la tecla **`M`** en consola (etapa ON): `SW4G1` pad 1 cae a < 0.4 V durante 0.5 s y los LEDs del módem
    apagan y vuelven. Sin el puente el pulso `MODEM_RST` no llega a nada. Anotar el puente en el acta de la unidad. Detalle en el [procedimiento de batería](../procedimientos/prueba-bateria-modem.md).

!!! note "V4 = la V5 en un Blackpill"
    Cotejada pad por pad en `hbox-watchdog-v4.kicad_pcb` contra `board_v5.h`: mismas redes, mismos pines
    del MCU, mismas direcciones I2C (PCF8574 `0x20`, SHT40 `0x44`, TMP102 `0x48`, SC16IS752 `0x4D`), mismo
    W5500 en SPI2 y misma K1 en `PB5`. **Una sola diferencia:** `ETH_INT` es `PB2` (J1.16) en vez de `PC0`.
    Por eso la V4 no necesita firmware propio: es `hbox_v5_bringup` compilado para Blackpill con
    `board_v4.h`. La V4 **se flashea por DFU solo con USB** (sin 24 V y con la batería desconectada). Ojo: en la V4
    ese USB también alimenta el riel de 5 V de la tarjeta y, con él, al W5500, cuya `INTn` llega a `PB2` = `BOOT1`.
    Si no aparece *STM32 BOOTLOADER*, se flashea la Blackpill fuera del zócalo
    ([procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md)).

!!! danger "Lo que NO se puede cruzar"
    - `hbox-v5-bringup_0.5.x.bin` (compilado para el F411RE soldado) en una **V3 o V4**: otro MCU y otro
      mapa de pines. La V4 usa **su propio binario** `hbox-tarjetaV4_…`, compilado para Blackpill.
    - `hbox-tarjetaV3_…` en una **V4**: maneja los LEDs de carga en PB12–PB15, que en la V4 son el SPI del W5500.
    - Cualquier binario de la carpeta `superseded/`: se conservan solo por trazabilidad.

### Versiones superadas

No se flashean. Están para identificar lo que una tarjeta vieja pueda traer y para volver atrás si una prueba de banco lo pide.

| Archivo | Por qué se retiró |
|---|---|
| [`superseded/hbox-tarjetaV3_3.0.4.bin`](superseded/hbox-tarjetaV3_3.0.4.bin) | Misma lógica que las unidades en campo (3.0.3) pero **sin telemetría en banda**: el monitor no ve nada en *Salud*. Sustituida por 4.0.0. |
| [`superseded/hbox-v5-bringup_0.5.6.bin`](superseded/hbox-v5-bringup_0.5.6.bin) · [`superseded/hbox-tarjetaV4_0.5.6.bin`](superseded/hbox-tarjetaV4_0.5.6.bin) | Pulso `MODEM_RST` por U13-P7 (solo con puente); sin puente el módem seguía sin encender en las ventanas, y un reset en batería dejaba la etapa apagada. Sustituida por 0.5.7 (despertar por reset del MCU; conserva el pulso). |
| [`superseded/hbox-v5-bringup_0.5.5.bin`](superseded/hbox-v5-bringup_0.5.5.bin) · [`superseded/hbox-tarjetaV4_0.5.5.bin`](superseded/hbox-tarjetaV4_0.5.5.bin) | **No usar.** Poner el UART del GNSS en alta impedancia no bastó: en reposo `3V3_MODEM` sigue en ~1 V y el módem no rearranca. Sustituida por 0.5.6, que resetea el módem desde el MCU (puente U13-P7 → SW4G1). |
| [`superseded/hbox-v5-bringup_0.5.4.bin`](superseded/hbox-v5-bringup_0.5.4.bin) · [`superseded/hbox-tarjetaV4_0.5.4.bin`](superseded/hbox-tarjetaV4_0.5.4.bin) | **No usar.** Su ciclo de etapa al volver el 5 V no apagaba de verdad al módem: el UART del GNSS seguía sosteniendo su riel, así que el módem no rearrancaba ni en batería ni al volver el vehículo (solo con reset). Sustituida por 0.5.5. |
| [`superseded/hbox-v5-bringup_0.5.3.bin`](superseded/hbox-v5-bringup_0.5.3.bin) · [`superseded/hbox-tarjetaV4_0.5.3.bin`](superseded/hbox-tarjetaV4_0.5.3.bin) | Ventana de 2 min, pero al volver el 5 V tras batería el módem podía quedarse en *latch* (oscuro hasta un reset). Sustituida por 0.5.4, que cicla la etapa al volver el 5 V. |
| [`superseded/hbox-v5-bringup_0.5.2.bin`](superseded/hbox-v5-bringup_0.5.2.bin) · [`superseded/hbox-tarjetaV4_0.5.2.bin`](superseded/hbox-tarjetaV4_0.5.2.bin) | Primera versión con reporte cada 10 min en batería, ventana mínima de 90 s: **insuficiente para que el módem entregara la posición**. Sustituida por 0.5.3 (120 s). |
| [`superseded/hbox-v5-bringup_0.5.1.bin`](superseded/hbox-v5-bringup_0.5.1.bin) · [`superseded/hbox-tarjetaV4_0.5.1.bin`](superseded/hbox-tarjetaV4_0.5.1.bin) | Última versión de campo antes del reporte cada 10 min en batería (en batería dejaba la etapa encendida hasta vaciar el paquete). Sirve para volver atrás si 0.5.3 da problemas en banco. |
| [`superseded/hbox-v5-bringup_0.4.0.bin`](superseded/hbox-v5-bringup_0.4.0.bin) | Versión de V5 sin `$PHLG` en banda. Sustituida por 0.5.1. |

### Firmware de bring-up — EinarBoard v5

| Archivo | Versión | SHA-256 | Uso |
|---|---|---|---|
| [**hbox-v5-bringup_0.5.7.bin**](hbox-v5-bringup_0.5.7.bin) | **0.5.7** (2026-09-26) — **campo + Modo B + batería (ventana 2 min / 10 min) con despertar por reset del MCU; pulso `MODEM_RST` por U13-P7 si hay puente; tecla `R`** — ⚠ sin prueba de banco; requiere servidor con soporte `DUTY` | `1acd5f46ddb76f14…` | Sección 5 del [procedimiento de prueba y flasheo v5](../procedimientos/v5-prueba-y-flasheo.md) y sección 5 del [ensamble](../procedimientos/v5-ensamble.md) (modo de banco `P` / `n`) |

Flasheo por DFU en **J11** (mantener **SW2**, pulsar y soltar **SW1**, soltar SW2):

```bash
dfu-util -a 0 -s 0x08000000:leave -D hbox-v5-bringup_0.5.7.bin
```

o con **STM32CubeProgrammer** → USB → Connect → Download del `.bin` en `0x08000000`.

!!! success "A/B 0.4.0 vs 0.5.1 — cerrado el 19-sep"
    El 18-sep por la tarde se reportó que con 0.5.1 la etapa RTK no encendía. **Resuelto:** 0.5.1 ensambla,
    enciende y reporta telemetría completa en el monitor desplegado. **Se embarcó con 0.5.1; desde el 26-sep la vigente es 0.5.7.** `0.4.0`
    queda en `superseded/` solo como referencia.

!!! note "Tarjetas ya flasheadas con cualquier versión anterior"
    Re-flashear con **0.5.7** por el mismo procedimiento DFU. **La primera línea de la consola tras reset dice la versión**
    (`hbox-v5-bringup 0.5.7 built …`): si la línea `STAT` no termina en `stack=…`, la tarjeta sigue con 0.1.1.

!!! tip "Consola 0.5.x"
    Líneas `EVT` en cada cambio (stack, ignición, 5 V, cargador, NMEA, fix), `STAT` con nombres cada 5 s y `$PHLG` cada 10 s
    (misma trama de salud que lee el servidor). Teclear `l` para la leyenda y `v` para los puntos de medición de la etapa RTK.
    Para encender la etapa RTK: `P` y luego `Y` (requiere 5 V en P2).

!!! warning "0.5.x = firmware de campo mínimo + telemetría y eventos en banda — AUTO de fábrica"
    Desde 0.4.0 el modo AUTO es el **de fábrica**: la etapa RTK se enciende sola 3 s después de ver 5 V en P2 — no hace falta consola
    ni teclear `A`. Incluye watchdog 16 s, ventilador (política v3.0.3), recuperación de enlace (ciclo de etapa si el F9P deja de
    hablar 60 s; LIMP tras 3 ciclos), LEDs de carga y color de estado, corte térmico 60 °C y corte de batería 3.40 V.
    **El cargador sigue APAGADO: el paquete es de un solo uso hasta el firmware de producción.** Anotarlo en el acta de la unidad.

    **0.5.7:** cada despertar de batería (≥ 10 min tras la última ventana) y cada regreso del 5 V tras batería es un **reset del
    MCU** (`NVIC_SystemReset`, lo mismo que el botón P10): arranca en ~4 s; sin 5 V la ventana abre de inmediato, con 5 V AUTO
    enciende la etapa a los 3 s. Se pierden uptime y contadores. Tecla `R` = ese reset ahora. Un reset por SW1/P10 en batería
    abre ventana en 60 s (antes dejaba la etapa apagada hasta que volviera el 5 V) y `P` se acepta en batería con vbat ≥ 3.60 V.

    **0.5.6:** 3 s después de cada encendido de etapa el MCU pulsa el reset del módem 500 ms por `U13` P7 (evento `MODEM_RST`,
    contador `mrst=` en `STAT`, tecla `M` = pulso manual). Con la etapa apagada PA9/PA10 quedan en alta impedancia sin pull-up.

    **0.5.5:** con la etapa apagada el UART del GNSS queda en alta impedancia (antes PA2 sostenía el riel del simpleRTK2B y, a través de él, el del módem: el módem
    nunca veía un power-on reset y quedaba oscuro hasta un reset de la tarjeta). Al volver el 5 V tras batería la etapa se cicla 10 s (`PWR_RETURN_CYCLE`).

    **0.5.2–0.5.7 — batería:** con 5 V perdidos la etapa ya no queda encendida hasta vaciar el paquete: ventana de reporte de 120–180 s
    cada 10 min (`DUTY_WAKE` / `DUTY_SLEEP next=<s>` / `DUTY_SKIP` / `DUTY_END`), ventilador y LEDs apagados en reposo, protecciones
    de batería (< 3.40 V) y temperatura (≥ 60 °C) por encima del ciclo. El MCU sigue despierto: el ahorro es la etapa (~2.3 W).

    **0.5.1 — diagnóstico:** `$PHLG` lleva además `up_s`, `pwr` (VEH/BATT), `v5min`/`vbat_min` (mínimos de la ventana de 30 s)
    y `bkp_n`; cada cambio de estado sale como `$PHEV,<up_s>,<CODIGO>,<detalle>` al servidor (misma línea de tiempo que los `EVT`).

    **0.5.0 — Modo B:** 10 s después de que el F9P empieza a hablar, el MCU conmuta K1 y la trama `$PHLG` viaja al servidor
    cada 30 s junto con el NMEA (columna **Salud** del monitor). En consola: `STAT … modoB=ON relay=… phlg_aire=…` (debe subir de
    1 en 1 cada 30 s). Si el MCU falla, K1 regresa solo al paso directo F9P→módem. `B` lo bloquea/permite para pruebas. Si se pierde el 5 V, la etapa **sigue encendida desde la batería**
    y la consola registra `EVT BACKUP inicio` / `BACKUP fin` con duración y tramas NMEA: esa es la prueba de respaldo.
    Se apaga sola si vbat < 3.40 V o temperatura > 50 °C. `A` de nuevo regresa a MANUAL. El cargador sigue apagado en todos los modos.

!!! warning "Solo para la tarjeta v5"
    Este firmware **no** es el de producción: solo prueba la tarjeta (reloj, USB, cristales, I²C,
    LEDs, ADC) sin encender la etapa RTK ni el cargador. **Nunca flashear `blackpillrtkcode_v3`
    (v3.0.3) en una v5.**

**Novedades de 0.5.x:** el `$PHLG` gana 5 campos nuevos (`up_s`, `pwr`, `v5min`, `vbat_min`, `bkp_n` — `vbat_min` caza los hundimientos de 50-200 ms de las ráfagas LTE que una foto cada 30 s nunca ve) y aparece `$PHEV`, una trama por cada cambio de estado. Los analizadores viejos ignoran los campos extra.

Notas de compilación y cambios: [README del firmware de bring-up](hbox-v5-bringup-README.md).

### Firmware de campo — tarjeta V3 (detalle)

!!! danger "Estos binarios todavía NO se flashean en una unidad de campo"
    Compilaron limpio el 19-sep y pasan el simulador, pero **ninguno ha corrido sobre una
    EinarBoard 1.0 real**. Hasta que ingeniería los pruebe en banco (RTK-003 o RTK-006) y quite
    este aviso, solo se usan en la mesa de ingeniería. Esto aplica sobre todo al **4.0.0**, que pone
    el MCU en línea con el enlace que lleva las correcciones RTK.

!!! tip "Prueba de banco del 4.0.0: en par"
    El 4.0.0 activa el Modo B por omisión. Aunque el A/B de V5 ya cerró bien, la primera prueba en
    una V3 real se hace **en par**: el binario publicado y uno compilado con `-DENABLE_MODOB=0`,
    sobre la misma unidad. Si el fix RTK cae al energizar K1, o `v5min` se hunde en ese instante,
    el sospechoso es la bobina de K1 llevando el riel al PFI del LTC4040.
    ```bash
    arduino-cli compile --fqbn "$FQBN" --build-property "compiler.cpp.extra_flags=-DENABLE_MODOB=0" \
      --output-dir build/v4-sinB blackpillrtkcode_v4
    ```

Es el firmware que gobierna la unidad en la máquina, distinto del de bring-up del v5. Se usa en el
[reflasheo en taller](../procedimientos/reflasheo-unidades.md).

| Tarjeta | Archivo | Estado |
|---|---|---|
| **V3** — flota desplegada | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) · 64 352 B · `a68a87ff…` | ⚠ compilado 19-sep, falta prueba de banco. El «4» es la versión del firmware, **no** la tarjeta |
| **V4** | [`hbox-tarjetaV4_0.5.7.bin`](hbox-tarjetaV4_0.5.7.bin) · 83 684 B · `5c8726da662cd047…` | ⚠ compilado 26-sep, falta prueba de banco. Es 0.5.7 para Blackpill (`-DHBOX_BOARD_V4`), DFU **solo con USB**; puente U13-P7 → SW4G1 opcional (respaldo) — [procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md) |

!!! danger "Mientras diga «pendiente», no hay binario aprobado"
    No flashees una unidad V3 o V4 con un archivo que no esté publicado aquí con su SHA-256. Los
    binarios de estas generaciones **no viven en el repositorio** (están en `.gitignore`): tienen que
    compilarse, probarse en banco y publicarse. El procedimiento de generación está en el
    [reflasheo §6](../procedimientos/reflasheo-unidades.md).

!!! warning "Un binario no sirve para otra generación"
    La polaridad del control de carga está **invertida** entre la tarjeta de producción y la de
    protoboard. Flashear el binario equivocado puede dejar la batería cargando justo cuando el
    firmware cree estarla protegiendo por temperatura — la falla #1 del RCA de junio.

## Parámetros del módem 4G NTRIP Master

La configuración se envía por el puerto USB **XBEE** del simpleRTK2B Pro a 115200 baudios, línea por
línea (solo las que empiezan con `$$$AS+`). Cada una debe contestar `OK`.

| Archivo | Qué es |
|---|---|
| [**4G_NTRIP_HelgenSRV-NMEA.example.txt**](4G_NTRIP_HelgenSRV-NMEA.example.txt) | **Plantilla** con todos los parámetros y sus nombres, con los valores sensibles en blanco |

!!! danger "El archivo con los valores reales no está aquí, y es a propósito"
    El archivo lleno contiene **usuario y contraseña del caster NTRIP y de la APN**. Publicarlo en el
    sitio sería ponerlo al alcance de cualquiera que tenga una cuenta de técnico, y meterlo al
    repositorio rompe un invariante del proyecto (*sin secretos en el repo, nunca*).

    **Cómo se obtiene:** pídelo a ingeniería para la unidad que vas a configurar. Llega por un canal
    directo, se usa y no se guarda en el equipo ni se reenvía.

Referencia rápida de los parámetros que más se consultan:

| Comando | Qué configura |
|---|---|
| `AS+I=1111` | Entra a modo configuración |
| `AS+A` · `AS+Q` · `AS+q` | APN: host, usuario, contraseña |
| `AS+S` · `AS+P` | Caster NTRIP: host y puerto |
| `AS+U` · `AS+M` | Caster: `usuario:contraseña` y mountpoint |
| `AS+B` | Velocidad del puerto (115200) |
| `AS+K` | **ID de estación** del módulo — se anota en el acta |
| `AS+r` · `AS+h` | Servidor secundario: IP y puerto |

## Firmware y configuración del simpleRTK2B Pro (ZED-F9P)

Aquí hay que separar dos cosas que se confunden:

| Qué | De dónde sale | Estado |
|---|---|---|
| **Firmware del ZED-F9P** | **Estándar de u-blox**, no es nuestro: [u-blox → ZED-F9P → Documentation & resources → Firmware Update](https://www.u-blox.com/en/product/zed-f9p-module). Serie **HPG**. Se carga con **u-center** (solo Windows) a 115200 | ✅ disponible en el sitio de u-blox |
| **Configuración de Helgen** (`.txt` de u-center) | **Nuestra.** Define UART1 a 115200 (que es lo que lee la tarjeta), UART2 a la velocidad del módem y qué mensajes NMEA salen | ⬜ **pendiente de publicar — este es el que de verdad falta** |

!!! warning "No actualices el firmware del F9P sin una razón concreta"
    El firmware de u-blox **no tiene nada que ver con nuestras fallas**: las correcciones llegan por
    el módem 4G, no por el GNSS, y en las capturas de junio los receptores estaban sanos. Actualizarlo
    es un proceso solo-Windows que puede dejar el receptor a medias, y **borra o invalida la
    configuración**, que es justo la parte que sí importa.

    Primero anota qué versión trae (**u-center → View → Messages → UBX-MON-VER**) y déjala así.
    Solo se actualiza si u-blox publica un arreglo para un problema que estemos viendo, y siempre en
    banco, nunca en una unidad instalada.

Para leer o cargar la configuración: u-center → *Tools → Receiver Configuration*. Después de cargar,
**guardar en FLASH** y reconectar para confirmar que sobrevive al reinicio — una configuración que
solo quedó en RAM se pierde al primer corte de energía, y así perdimos tiempo en junio.

## Cómo se publica un firmware nuevo

Para que un archivo pueda aparecer en esta página tiene que pasar por aquí. No es burocracia: un
binario mal compilado deja unidades muertas en el patio.

- [ ] Compilado con el `TARGET_` correcto para esa generación de tarjeta.
- [ ] **Probado en banco sobre hardware real**, no solo compilado sin errores.
- [ ] Verificada la polaridad del control de carga sobre la tarjeta.
- [ ] Nombre con **tarjeta y versión**: `hbox-tarjetaV3_X.Y.Z.bin`. La versión del firmware nunca se infiere de la tarjeta ni al revés.
- [ ] Su línea en `SHA256SUMS.txt`.
- [ ] Anotado en el `CHANGELOG.md` del repositorio de firmware, con fecha y quién lo probó.
- [ ] Actualizada la tabla de esta página.

Los archivos viven en `docs/descargas/` del repositorio `hbox-docs` y se publican con
`./scripts/deploy.sh`. Los `.bin` de firmware de campo están en `.gitignore` por tamaño y por
control de versiones: se copian a mano a esa carpeta antes de publicar.

## Herramientas

- **STM32CubeProgrammer** (Windows/macOS/Linux): https://www.st.com/en/development-tools/stm32cubeprog.html
- **dfu-util** (macOS: `brew install dfu-util`; Linux: `apt install dfu-util`)
- Terminal serie: CoolTerm, `screen /dev/tty.usbmodem* 115200`, o el monitor serie de Arduino IDE