La respuesta corta
Actualizar el firmware de un dispositivo desde la app del móvil tiene una regla por encima de todas: el dispositivo no puede quedarse inservible. Ni si se corta la luz, ni si el usuario se aleja con el teléfono, ni si la imagen nueva arranca y falla.
Eso no se resuelve en la app: se resuelve en el diseño del dispositivo. Y si el firmware no está preparado, la app no puede compensarlo por mucho cuidado que ponga.
Tomando ESP-IDF como referencia —porque su esquema es representativo de cómo se hace bien—, las piezas son un esquema de particiones con dos ranuras, una confirmación explícita de que la versión nueva funciona, y reversión automática si esa confirmación no llega.
El esquema que impide el ladrillo
- Partición de fábrica: la app inicial, que no se modifica nunca.
- Ranuras OTA (
ota_0,ota_1): alternan para guardar las imágenes nuevas. Nunca se sobrescribe la que está funcionando. - Partición de datos OTA: dos sectores de 4 KB que registran cuál arranca la próxima vez, con redundancia para sobrevivir a un corte de corriente.
El gestor de arranque decide qué imagen ejecutar leyendo esos datos. Si están borrados, arranca la de fábrica si existe; si no, la primera ranura disponible.
Ese diseño es el que permite que, aunque se corte la alimentación en mitad de la actualización, el chip siga operativo. Es la propiedad que hay que exigir al fabricante o al equipo de firmware antes de prometer actualizaciones por la app.
La confirmación: lo que separa una OTA seria de una temeraria
Una imagen recién grabada no se considera buena. Pasa por estados:
| Estado | ¿Arranca? | Qué significa |
|---|---|---|
ESP_OTA_IMG_VALID | Sí | Confirmada como funcional |
ESP_OTA_IMG_NEW | Sí, una vez | Pendiente de validar en el primer arranque |
ESP_OTA_IMG_PENDING_VERIFY | No | Esperando confirmación; pasa a abortada si se reinicia |
ESP_OTA_IMG_INVALID | No | Falló la validación |
Después de arrancar, la aplicación tiene que llamar explícitamente a esp_ota_mark_app_valid_cancel_rollback() para confirmar que funciona. Si no lo hace en ese arranque, se revierte automáticamente a la versión anterior.
La consecuencia de diseño es la que importa: esa llamada no debe hacerse al principio del arranque. Debe hacerse cuando el dispositivo ha demostrado que hace lo que tiene que hacer —que se conecta, que lee su sensor, que responde—. Confirmar en la primera línea de código convierte la reversión automática en un adorno.
Ataques y firmas
Dos mecanismos que conviene tener decididos antes de la primera entrega:
- Anti-reversión. Con la opción correspondiente activada, el gestor de arranque rechaza firmware con una versión de seguridad inferior a la grabada en eFuse. Impide que alguien reinstale una versión antigua con una vulnerabilidad conocida.
- Verificación de firma. Se pueden validar imágenes firmadas con Secure Boot v2 incluso sin Secure Boot activado. Si el canal de actualización es la app del usuario, esto no es opcional: sin firma, quien controle el móvil controla el firmware.
Lo que le toca a la app
Con el dispositivo bien diseñado, el trabajo de la app es de experiencia y de resiliencia:
- Transferencia por trozos, con reanudación. Las transferencias se interrumpen: el usuario se mueve, el teléfono cambia de red, entra una llamada. Debe poder continuar donde iba en lugar de empezar de cero.
- Comprobaciones antes de empezar: batería del dispositivo y del teléfono, versión actual, compatibilidad de hardware, espacio.
- Una sola actualización a la vez, y bloqueo explícito de acciones incompatibles mientras dura.
- Progreso honesto. Incluida la fase de escritura y verificación, que en BLE puede ser lenta y silenciosa. Una barra que se queda quieta al 98 % genera más llamadas a soporte que un fallo.
- Qué pasa si el usuario se va. El caso más común y el peor documentado. Si se pierde la conexión a mitad, el dispositivo tiene que quedar en su versión anterior, funcionando, y la app tiene que poder reanudar la próxima vez.
- Registro de resultados: qué versión, en qué dispositivo, con qué resultado. Sin telemetría de actualizaciones, una campaña de firmware es a ciegas.
Los modos de fallo que hay que probar a propósito
No basta con probar el camino feliz. Estos se prueban uno a uno, con el hardware delante:
- Corte de alimentación durante la escritura.
- Firmware nuevo que arranca y no confirma: comprobar que revierte.
- Firmware nuevo que ni arranca.
- Interrupción de la transferencia y reanudación.
- Intento de instalar una versión anterior con anti-reversión activo.
- Imagen sin firmar o con firma inválida.
- Sin versión previa a la que volver — la reversión falla si no hay una app anterior, y ese caso hay que preverlo en la tabla de particiones.
El punto siete es el que más se olvida y el que convierte una precaución en una falsa sensación de seguridad.
Antes de estimar
- ¿El firmware ya soporta OTA con dos ranuras y reversión, o hay que construirlo?
- ¿Por qué canal viaja la imagen: BLE, Wi-Fi directo, red local? El tiempo de transferencia cambia por un orden de magnitud.
- ¿Están firmadas las imágenes, y quién custodia la clave?
- ¿Anti-reversión activado? Si sí, la política de versiones de seguridad hay que definirla antes, porque el eFuse no se deshace.
- ¿Qué parque hay ya en la calle y en qué versiones?
La quinta suele ser la peor noticia del proyecto: actualizar dispositivos que salieron sin OTA no es un proyecto de software.
Es el tipo de trabajo que hacemos en integración con hardware, donde la app y el firmware se diseñan juntos porque por separado no funcionan.
Fuente primaria, consultada el 14 de agosto de 2026: Over The Air Updates (OTA) en la documentación de ESP-IDF.
