Respuesta breve
Una actualización robusta necesita una ruta definida para recuperar un equipo que pueda arrancar. Antes de programar la transferencia, decida qué debe ocurrir si se interrumpe la alimentación durante el borrado, la escritura, la comprobación o la activación de la nueva imagen.
Distinga el bootloader de sistema del proceso del producto
El bootloader de sistema integrado en STM32 y un bootloader de producto no resuelven necesariamente la misma tarea. Las interfaces y condiciones de entrada dependen del dispositivo; ST las describe en AN2606. Compruebe la referencia exacta, no solo la familia. STMicroelectronics — AN2606
Un programador puede ser suficiente en el laboratorio y resultar inaccesible cuando el equipo esté instalado. Defina quién podrá llegar al dispositivo averiado y qué conexión seguirá disponible. Esa situación determina las necesidades de recuperación y mantenimiento.
Calcule la memoria antes de elegir la arquitectura
Incluya bootloader, aplicación, configuración y espacio de trabajo. Reserve un margen justificado para la evolución de la aplicación. La posibilidad de mantener dos imágenes internas o la necesidad de memoria externa debe calcularse para el microcontrolador elegido.
MCUboot describe, entre otras opciones, actualizaciones de prueba con confirmación y retorno a la imagen anterior. Es una arquitectura posible, no una propiedad automática de cualquier proyecto STM32. Hay que comprobar su implementación y requisitos de memoria. MCUboot — Bootloader design
Active una imagen solo tras comprobarla
Defina estados separados: recibida, verificada, arrancada a prueba y confirmada. Terminar una descarga no debe equivaler automáticamente a autorizar el arranque. Compruebe compatibilidad con la revisión de hardware, tamaño permitido, versión e integridad.
Una suma de comprobación detecta determinados errores de transmisión, pero no acredita un origen de confianza. Si el análisis de amenazas lo requiere, diseñe una verificación criptográfica de firma con una raíz de confianza protegida. La gestión de claves y la autorización de versiones pasan entonces a formar parte del producto.
Reproduzca los fallos en distintas etapas
Interrumpa la alimentación en varios puntos del proceso y registre el estado al volver a encender. Pruebe también una imagen incompleta, una identificación de hardware incorrecta y una aplicación que arranca pero no supera su comprobación de funcionamiento.
Un criterio de aceptación puede ser: después de cada interrupción acordada, arranca la versión anterior aprobada o queda disponible el procedimiento documentado de recuperación. La posibilidad de reiniciar automáticamente depende de la función del equipo; no es adecuada por defecto para cualquier aplicación.
Contenido del plan de actualización
- Modelo de MCU, revisión de hardware y cálculo de memoria.
- Ruta de recuperación accesible y condiciones de uso.
- Estados de la imagen y reglas para confirmar el arranque.
- Migración de los datos de configuración entre versiones.
- Resultados de cortes de alimentación con identificadores de firmware.
Preguntas frecuentes
¿Dos bancos Flash son suficientes?
No. También hacen falta una secuencia correcta, datos de estado coherentes y una decisión de arranque comprobada. Las características de la Flash dependen del dispositivo.
¿Todo producto necesita actualizaciones OTA?
No. Puede ser apropiada una interfaz local de mantenimiento. La elección depende de accesibilidad, coste de parada, procedimiento de servicio y requisitos de confianza del firmware.
Fuentes técnicas
Servicio relacionado