Mejora ARM por aire

Crearemos una placa ARM con un módem GSM integrado.
Queremos poder actualizar el firmware de ARM por aire.

¿Existe alguna solución buena, confiable y de código abierto para eso?
Si no, ¿hay un sistema operativo pago con esta función?

wireless arm firmware

— hotips
fuente

ARM es bastante genérico: hay muchos fabricantes que incorporan arquitecturas ARM, y algunos de ellos pueden proporcionar esa característica.

— clabacchio

Una información más específica sobre qué chip / familia ARM está planeando usar sería bueno. Muchos, si no todos los microcontroladores Cortex-M admiten escribir en flash desde el código de usuario. Existen implementaciones de código abierto de ejemplo, como el gestor de arranque Maple leaflabs.com/docs/bootloader.html , y creo que he visto una actualización de firmware a través de un enlace de radio compatible con algún quadcopter.

— Thorn,

No hemos elegido el dispositivo ARM en este momento;)

— hotips

El gran problema con las actualizaciones de firmware es cómo forzar el chip al modo de actualización una vez que hay algún problema con el firmware. Cuando tiene acceso al chip, puede restablecerlo y forzar un pin de carga de arranque alto, pero ¿cómo va a hacerlo por el aire? La única solución confiable que puedo imaginar es tener un segundo chip (no actualizable) que maneje la comunicación básica y pueda actualizar el chip principal. Después de resolver ese problema, la carga de arranque real puede ser tan simple como usar (por ejemplo) el gestor de arranque integrado en el chip (por ejemplo, los LPC uC que conozco tienen un cargador de arranque en serie).

— Wouter van Ooijen

@Hernan Eso haría posibles modos de falla sutiles, como un chip (de alguna manera ejecutando el código incorrecto) manteniendo el otro en el reinicio. La única solución realmente confiable es mantener las funciones en un chip tan simple que nunca necesitará actualizarlo.

— Wouter van Ooijen

Respuestas:

No conozco ninguna solución prefabricada, pero describiré cómo lo resolví en un proyecto. No es totalmente 'inquebrantable', pero no estoy al tanto de que haya fallado en miles de actualizaciones. Para esta aplicación, una tasa de falla muy baja aún sería 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 de inicio de actualización de firmware borra un área de memoria reservada en un SPI Flash externo. Devuelve un error si la unidad está funcionando con su batería de respaldo o si está funcionando con energía externa pero el estado de carga de la batería es inferior al 25%.
Un comando de escritura de bloque acepta una dirección de desplazamiento y datos que se escriben en la memoria Flash externa en pequeños fragmentos. El protocolo de nivel superior se encarga de la detección de errores y retransmisiones. Después de escribir cada bloque, se vuelve a leer 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 toda la imagen para su posterior verificación. Si eso coincide con el contenido de la memoria Flash externa y las condiciones de alimentación siguen siendo correctas, la misma longitud y 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 un reinicio de vigilancia.
El gestor de arranque (que se encuentra en un área protegida contra escritura del Flash del 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 del Flash externo al área principal del programa del Flash del ARM.
La información de actualización pendiente se borra de EEPROM y un bucle forzado fuerza otro reinicio. Esta vez, el gestor de arranque iniciará la aplicación principal normalmente.

Si bien nunca he visto fallar la fase de actualización, probar nuevas versiones de firmware antes de la implementación es crucial con este método. Si una nueva versión no es capaz de conectarse a la red GSM y aceptar futuras actualizaciones, requerirá una actualización de firmware en el sitio.

— PeterJ
fuente

¿Estás ejecutando Linux o un RTOS, o bare metal? Si usa Debian puede tomar una instantánea del sistema de archivos actual, realizar una actualización a través de "apt-get" y luego mantener o revertir los cambios dependiendo de si funcionó o no.

— fred basset
fuente

Tenemos Linux y bare metal dependiendo de la aplicación ;-)

— hotips 05 de

Si tiene Linux, puede aprovechar gran parte de esa infraestructura. La forma en que manejo las actualizaciones en mi proyecto actual es crear archivos .deb para las aplicaciones personalizadas, luego usar apt-get update para actualizar el sistema. También estoy experimentando con btrfs. Ese sistema de archivos le permite tomar instantáneas. Entonces, mi plan es tomar una instantánea de los directorios deseados, probar y actualizar, y si no funcionó, revertir la instantánea. Si está en el metal desnudo, entonces probablemente deba ir con el enfoque habitual de doble memoria, una imagen para el último código de trabajo y otra para el código recién descargado.

— fred basset