¿Cómo puedo hacer actualizaciones incrementales con un flash que solo se puede borrar en bloque?

Guión

Quiero actualizar un dispositivo IoT de bajo costo por aire con un nuevo firmware que actualice los microcontroladores del dispositivo. La memoria del microcontrolador es memoria flash en el rango de 32k a 128k (cada centavo cuenta). Esta memoria barata tiene una limitación importante: solo se puede borrar en bloque.

Pregunta

¿Eso significa que no puedo hacer actualizaciones diferenciales ( delta )? ¿Siempre tengo que actualizar toda la memoria del controlador (o al menos partes importantes)?

Quiero reducir la necesidad de flashear todo y arriesgarme a bloquear el dispositivo lo más posible. ¿Existen estrategias existentes para flashear microcontroladores en el aire?

La respuesta simple es sí: necesita suficientes bloques de flash para soportar el gestor de arranque y las imágenes de código A / B si desea una alta confiabilidad. Antes de activar la nueva imagen, puede escribir todo, verificarlo y volver a intentarlo.

Sin embargo, esta es una estrategia costosa / confiable y hay cosas que puede hacer para reducir los gastos generales. El soporte de bajo nivel para las actualizaciones de OTA también puede venir como parte del firmware del sistema operativo o del sistema operativo, por lo que puede evitar la suya propia a menos que desee aprender. Esta característica podría describirse como FOTA.

Particionar su base de código permite actualizaciones incrementales, en el mejor de los casos el gestor de arranque puede abrir la conexión de red, descargar y verificar el código sin necesidad de ningún código de usuario alternativo. Con una puerta de enlace local, la administración de esta tarea se puede delegar desde los puntos finales de bajo costo.

Muchos dispositivos tienen una pequeña cantidad de flash de borrado de palabras, e incluso si falla esto, generalmente puede establecer bits sin necesidad de borrar un bloque completo. Estas características se pueden utilizar para manipular tablas de salto y unir código que se actualiza en bloques de tamaños de bloque. Incluso si inicialmente planificó un espacio de código A / B completo, es posible que deba recurrir a un esquema más complejo cuando la base de código crece demasiado.

Para aclarar la funcionalidad que se puede lograr con una solución sofisticada de firmware por aire, el gestor de arranque y potencialmente una pila de comunicación primaria pueden permanecer residentes mientras se vuelve a flashear el espacio de aplicación de usuario restante. Esto no necesita ninguna sobrecarga (particularmente si la partición del bloque es suave). En el escenario donde la pila de comunicación necesita actualizarse, la región generalmente utilizada para el código de la aplicación se puede usar temporalmente durante la descarga y la verificación. Lograr esto requiere cierto soporte en el SoC, pero los dispositivos de segunda y tercera generación diseñados con esto en mente ya existen.

Quiero reducir la necesidad de flashear todo y arriesgarme a bloquear el dispositivo lo más posible. ¿Existen estrategias existentes para flashear microcontroladores en el aire?

Además de su código que realiza la actualización que sería relativamente estática, debe mantener dos imágenes en su almacenamiento: una imagen activa y una imagen de respaldo. Siempre que necesite actualizar, hágalo en la copia de seguridad, luego cambie eso para que esté activo. Una vez estable, actualice la imagen activa anterior que ahora debería ser su copia de seguridad.

Con eso en mente, puede usar algoritmos de nivelación de desgaste al actualizar ambas imágenes. El código para tales algoritmos podría tomar alrededor del 10-15% del almacenamiento total, pero vale la pena para extender la vida útil del dispositivo.

La nivelación de desgaste generalmente es administrada por el controlador de flash, que utiliza un algoritmo de nivelación de desgaste para determinar qué bloque físico usar cada vez que se programan datos. Hay dos tipos de nivelación de desgaste de la unidad de estado sólido (SSD): dinámica y estática. Los grupos de nivelación de desgaste dinámico borraron los bloques y seleccionan el bloque con el conteo de borrado más bajo para la próxima escritura.

La nivelación de desgaste estático, por otro lado, selecciona el bloque objetivo con el recuento de borrado general más bajo, borra el bloque si es necesario, escribe nuevos datos en el bloque y garantiza que los bloques de datos estáticos se muevan cuando su recuento de borrado de bloques está por debajo de un cierto umbral Este paso adicional de mover datos puede disminuir el rendimiento de escritura debido a la sobrecarga en el controlador flash, pero la nivelación de desgaste estático es considerablemente más efectiva que la nivelación de desgaste dinámica para extender la vida útil de los dispositivos de estado sólido.

( Techtarget.com: desgaste de nivelación )

Freescale Semiconductor describe una forma sólida de actualización de firmware por aire para sus microcontroladores Kinetis .

Se llama: Program Flash Memory Swap .

Sistemas que utilizan intercambio de memoria flash

En dispositivos con dos o más bloques flash internos que admiten el intercambio, se puede intercambiar la dirección de la base de memoria de cada bloque flash. La ubicación de la dirección de cada bloque flash se intercambiará en el mapa de memoria lógica del dispositivo. Después de un reinicio, el sistema de intercambio flash incorporado esencialmente selecciona qué software se ejecuta por la ubicación del bloque flash en el mapa de memoria lógica. Esto permite un sistema de copia de seguridad de código con la facilidad adicional de programación. Puede ejecutar fuera de un bloque mientras borra / programa el otro bloque. En los dispositivos Kinetis, el sistema de intercambio flash supervisa / controla todos los pasos para cambiar de la aplicación anterior a la nueva; Existe una garantía adicional de operación confiable en el caso de una pérdida de energía durante uno de esos pasos.

Ventajas

• Facilidad de programación. La aplicación siempre se ejecuta fuera del bloque inferior en el mapa de memoria.
• Pérdida de potencia tolerante.
• No se requiere gestor de arranque. Sin demora para el inicio de la aplicación principal.
• Muy adecuado para un sistema operativo multitarea. Mínimo tiempo de inactividad de la aplicación. En un sistema multitarea, es posible continuar ejecutando las tareas principales de la aplicación mientras se ejecutan tareas en segundo plano para actualizar la nueva copia de la aplicación.
• Copia de seguridad del código. Posible volver a la aplicación de trabajo conocida.

Desventajas

• Se requiere espacio adicional de memoria flash para almacenar la copia de seguridad.

Puede actualizar bloques y luego intercambiarlos.

El documento vinculado contiene una descripción detallada.

Asegura actualizaciones de firmware más seguras, pero como requiere más memoria flash, ciertamente cuesta más . Tampoco es aplicable a ningún tipo de microcontrolador, solo aquellos que admiten el intercambio interno de bloques flash.