Actualizaciones de firmware con recuperación y reversión

Una actualización de firmware llega a un dispositivo que no tiene pantalla ni un conector de servicio que el cliente pueda usar. La descarga termina, el dispositivo se reinicia y nunca vuelve a conectarse. Un diseño de recuperación debería responder qué pasa después antes de que esa actualización se envíe.

Ninguna configuración de bootloader puede garantizar que un dispositivo nunca quede inutilizable. Las fallas de hardware, el almacenamiento dañado y los errores ajenos al mecanismo de actualización siguen importando. La meta práctica es más acotada: identificar las fallas de las que el producto debe recuperarse, elegir un esquema de actualización que soporte esas recuperaciones y demostrar el comportamiento esperado en el hardware y el software que realmente se envían.

Esta es una lista de verificación de planeación para ese trabajo. Distingue entre aceptar una imagen, iniciarla y decidir que es adecuada para seguir corriendo.

Nombra la falla antes de elegir un mecanismo

Una descarga dañada y una aplicación correctamente firmada que falla son problemas distintos. Una interrupción de la alimentación durante un borrado es otro más. Escribe una tabla corta de fallas con el resultado requerido para cada caso.

Para una descarga incompleta, el resultado podría ser que el firmware actual siga operando y que la actualización pueda reiniciarse. Para una aplicación candidata que falla sus diagnósticos de arranque, podría ser un regreso a la imagen anterior que funcionaba. Para metadatos de actualización dañados, identifica el mecanismo que determina qué imagen sigue siendo arrancable. Evita un requisito genérico que simplemente diga «soportar OTA».

Separa la autenticidad de la imagen de la salud de la aplicación. Una firma puede establecer que una imagen fue autorizada por el titular de una llave de firma de confianza; no prueba que la lógica de la aplicación funcione. Un diseño de recuperación tiene que atender ambas.

Identifica también el alcance de la actualización. Reemplazar solo una aplicación es una operación distinta de cambiar un esquema de particiones, el bootloader, el firmware del radio o la configuración almacenada. No supongas que una afirmación de recuperación para una operación cubre todas las demás.

Elige una organización de memoria con una ruta de recuperación documentada

La documentación de diseño de MCUboot describe varias estrategias de actualización, incluyendo el intercambio de imágenes, las actualizaciones de solo sobrescritura y la ejecución directa. Sus restricciones y su comportamiento de recuperación son distintos. En particular, el modo de solo sobrescritura no ofrece la misma capacidad de revertir que una estrategia de intercambio configurada para probar y revertir.

Usa la documentación del port y del release elegidos para determinar los slots, metadatos, geometría de borrado y espacio de trabajo requeridos. Presupuesta esas áreas antes de fijar el límite de tamaño de la aplicación. Inspecciona la configuración de compilación resultante; la sola presencia de una partición secundaria no es prueba de que la recuperación esté habilitada.

Para la revisión del producto, dibuja el mapa real del flash y etiqueta lo que se escribe en cada fase. Muestra dónde llega el candidato, qué sigue disponible durante esa escritura, cómo cambia la elección de arranque y cómo se reconoce una operación interrumpida al reiniciar. Si un paso no tiene un comportamiento de recuperación documentado, es una pregunta de diseño por resolver y no una suposición que se deja en el dibujo.

El mecanismo elegido también debe ajustarse al ciclo de vida esperado de las actualizaciones. Revisa la resistencia del flash y la cantidad de escritura involucrada contra la documentación del hardware correspondiente. No existe un tamaño de área de scratch ni un número de actualizaciones que sirva para todos los dispositivos.

Decide qué significa un arranque exitoso

Con un esquema adecuado de probar y confirmar, iniciar una imagen candidata es provisional. La confirmación de la aplicación marca un punto de control después del cual el release se acepta. Decide qué necesita establecer ese punto de control para este producto.

La documentación OTA de ESP-IDF describe la confirmación controlada por la aplicación y la reversión después de que una aplicación sin confirmar se reinicia. Los detalles dependen de la configuración habilitada y de la disponibilidad de una imagen de respaldo elegible. También distingue entre la confirmación del arranque y los diagnósticos que realiza el código de la aplicación. Revisa la versión real del framework y sus ajustes en lugar de suponer que un valor predeterminado ofrece las verificaciones requeridas.

Elige diagnósticos que revelen fallas importantes del firmware sin hacer que condiciones externas normales parezcan un mal release. Por ejemplo, exigir una conexión a internet antes de confirmar puede rechazar un firmware que funciona cuando el router del cliente está apagado. Por el contrario, confirmar antes de que el cliente de actualización pueda inicializarse puede aceptar un firmware que no puede recibir una reparación. Define ese compromiso de forma explícita.

Una aplicación colgada puede necesitar un mecanismo de reset antes de que un bootloader pueda hacer otra selección. Revisa la operación del watchdog y el comportamiento del reset junto con el diseño de recuperación. No describas una bandera de confirmación como protección contra todo posible cuelgue o ciclo de arranque.

Mantén los datos persistentes compatibles con la recuperación

Revertir el ejecutable es solo una parte de devolver un producto utilizable. Revisa los ajustes, la calibración, las credenciales y otros datos persistentes que la nueva aplicación puede modificar antes de la confirmación.

Si el firmware anterior no puede leer un formato de datos nuevo, volver a su imagen puede no restaurar la operación. Planea cuándo ocurren las migraciones, si la versión anterior todavía puede leer los datos y qué pasa si la migración se interrumpe. El enfoque correcto depende del formato de almacenamiento y de los requisitos del producto; debe probarse junto con la actualización del ejecutable.

Incluye la compatibilidad del backend en la misma revisión. Un dispositivo recuperado sigue necesitando los servicios que su operación y sus futuras actualizaciones requieren. Un arranque exitoso que no puede recibir el siguiente release es un resultado de recuperación incompleto.

Planea la versión de seguridad y el proceso de firma

La reversión de recuperación y la protección de seguridad contra reversión (anti-rollback) resuelven problemas distintos. La primera restaura una imagen que funciona después de una actualización fallida. La segunda puede impedir que un atacante instale una imagen anterior vulnerable. Sus políticas deben coincidir sobre qué respaldo sigue siendo elegible.

La documentación de la herramienta de imágenes de MCUboot ofrece opciones separadas de versión de imagen y de contador de seguridad. Esas opciones de empaquetado no son, por sí solas, prueba de que un destino particular aplique la política de seguridad prevista. Revisa juntos la configuración del bootloader y el estado de confianza del destino, especialmente antes de un cambio irreversible de contador o de fusible.

Mantén controlados los permisos de firma y registra qué llave y qué compilación produjo cada artefacto de release — el mismo registro que la Ley de Ciberresiliencia de la UE ya espera que tenga un producto conectado. Planea el reemplazo y la recuperación de llaves usando las capacidades realmente aprovisionadas en el producto. Evita suponer que la configuración de llaves se puede cambiar de forma remota solo porque las actualizaciones de la aplicación funcionan.

Prueba la combinación que se envía

Conserva el binario del bootloader de producción y la configuración de particiones junto con la evidencia del release. La guía de compatibilidad del bootloader de Espressif recomienda específicamente probar las actualizaciones OTA de un producto existente usando su binario de bootloader desplegado. Una placa de desarrollo actual puede tener un punto de partida distinto al de las unidades ya instaladas.

En hardware de calificación, ejercita los casos de falla identificados en el plan:

• Interrumpe la descarga y confirma que un intento posterior pueda recuperarse.
• Presenta una imagen truncada y, donde se haya configurado la verificación de firmas, una imagen firmada con una llave no confiable.
• Reinicia un candidato antes de la confirmación y observa el comportamiento de respaldo definido.
• Interrumpe la alimentación en las fases relevantes de borrado, escritura, selección y confirmación.
• Revisa el comportamiento de los datos persistentes tras una actualización exitosa y tras una recuperación.
• Verifica que la versión recuperada pueda recibir una actualización válida posterior.

Registra el firmware inicial, el bootloader, la revisión de hardware, la inyección de la falla y el resultado observado. Una prueba que pasa respalda ese caso probado; no es una garantía universal. Usa un despliegue por etapas y un estado observable de versión y recuperación para limitar el impacto de los problemas que no se encontraron durante la calificación.

Para una revisión de la ruta de actualización, trae el MCU, el mapa del flash, el bootloader desplegado, la versión del framework, el transporte de actualización y el comportamiento de recuperación que necesita el producto. Esos datos convierten «haz que las actualizaciones sean confiables» en decisiones de diseño y pruebas concretas.