226 lines
15 KiB
Markdown
226 lines
15 KiB
Markdown
# 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.1.bin`](hbox-tarjetaV4_0.5.1.bin) | ⚠ compilado 22-sep, **sin prueba de banco** |
|
||
| **V5** — `hbox-watchdog-v5`, lote de 15 | STM32F411RET6 soldado | `hbox_v5_bringup` (0.5.1) | [`hbox-v5-bringup_0.5.1.bin`](hbox-v5-bringup_0.5.1.bin) | ✅ **en despliegue** |
|
||
|
||
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*.
|
||
|
||
!!! 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`. Como `PB2` es `BOOT1` en el F411, la V4 **se flashea por DFU solo con USB** (sin 24 V),
|
||
para que el W5500 apagado no pueda sostener `BOOT1` en alto.
|
||
|
||
!!! danger "Lo que NO se puede cruzar"
|
||
- `hbox-v5-bringup_0.5.1.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.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.1.bin**](hbox-v5-bringup_0.5.1.bin) | **0.5.1** (2026-09-18) — **campo + Modo B / telemetría — EN PRUEBA** (reportado: etapa RTK no enciende) | `e1f351084e803306…` | 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.1.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 embarca con 0.5.1.** `0.4.0`
|
||
queda en `superseded/` solo como referencia.
|
||
|
||
!!! note "Tarjetas ya flasheadas con cualquier versión anterior"
|
||
Re-flashear con **0.5.1** por el mismo procedimiento DFU. **La primera línea de la consola tras reset dice la versión**
|
||
(`hbox-v5-bringup 0.5.1 built …`): si la línea `STAT` no termina en `stack=…`, la tarjeta sigue con 0.1.1.
|
||
|
||
!!! tip "Consola 0.5.1"
|
||
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.1 = 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.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.1.bin`](hbox-tarjetaV4_0.5.1.bin) · 79 452 B · `4528187f9d675bca…` | ⚠ compilado 22-sep, falta prueba de banco. Es 0.5.1 para Blackpill (`-DHBOX_BOARD_V4`), DFU **solo con USB** |
|
||
|
||
!!! 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
|