No tengo conocimiento de ninguna solución prefabricada, pero describiré cómo lo abordé en un proyecto. No es totalmente "no bloqueable", pero no estoy al tanto de que haya fallado en miles de actualizaciones. Para esta aplicación, una tasa de falla muy baja sería aún más barata que tener que acceder a las unidades.
La aplicación principal tiene tres tipos de paquetes adicionales agregados a su protocolo de comunicación normal que incluye detección de errores y una estrategia de reintento en la parte superior:
-
Un comando para comenzar la actualización del firmware borra un área de memoria reservada en un SPI Flash externo. Devuelve un error si la unidad se está ejecutando desde su batería de respaldo o si se está ejecutando desde una fuente de alimentación externa, pero el estado de carga de la batería es inferior al 25%.
-
Un comando de bloque de escritura acepta una dirección de desplazamiento y los datos que se escriben en la memoria Flash externa en pequeños bloques. El protocolo de nivel superior se encarga de la detección de errores y las retransmisiones. Después de que se escribe cada bloque, se lee y se verifica antes de que se reconozca el comando.
-
Un comando para finalizar la actualización del firmware incluye la longitud que debe tener el firmware recibido junto con un CRC32 de la imagen completa para una verificación adicional. Si coincide con el contenido de la memoria Flash externa y las condiciones de energía aún están bien, la CRC32 se transfiere a un área EEPROM junto con un 'número mágico' para indicar que hay una actualización de firmware pendiente.
-
Se ejecuta un bucle duro en la aplicación principal para forzar el reinicio de un watchdog.
-
El gestor de arranque (que se encuentra en un área protegida contra escritura del Flash de ARM) ve el número mágico en EEPROM y una vez más verifica el CRC32 de la imagen. Si todo está bien, transfiere la imagen de Flash externo al área principal del programa de Flash de ARM.
-
La información de actualización pendiente se borra de EEPROM y un bucle forzado obliga a otro reinicio. Esta vez, el cargador de arranque iniciará la aplicación principal normalmente.
Aunque nunca he visto fallar la fase de actualización probar versiones nuevas de firmware antes de implementar es crucial usar este método. Si una nueva versión no es capaz de conectarse a la red GSM y aceptar futuros comandos de actualización, se requerirá una actualización de firmware en el sitio.