Cómo realizar actualizaciones de firmware sin detener la ejecución del firmware

Las aplicaciones basadas en sensores del Internet de las Cosas (IoT) se están expandiendo, así como el tamaño y la complejidad del firmware del microcontrolador en el punto final de IoT. Este firmware debe ser más eficiente para acelerar la ejecución, que es una de las razones por las que las actualizaciones de firmware de flash en el campo son una necesidad. Sin embargo, la actualización segura del firmware sobre el terreno suele requerir la detención de la ejecución del firmware mientras se realiza la actualización. Dependiendo de la arquitectura, el tamaño de la actualización y la velocidad de la red, esto se puede lograr en tan rápido como un minuto o tanto como una hora. Para las aplicaciones críticas este retraso puede ser inaceptable.

En este artículo se explican las consideraciones para la actualización del firmware basado en la interrupción en el campo y la necesidad de seguir ejecutando el firmware de la aplicación mientras se realiza la actualización. Luego presenta el microcontrolador PIC32MZ2048EFH144T-I/PH de Microchip Technology y muestra cómo se puede usar para ejecutar el firmware mientras que simultáneamente recibe el firmware actualizado a través de una red.

La importancia de las actualizaciones de firmware

El firmware se actualiza por cuatro razones principales: para corregir errores en el código, para añadir o mejorar características, para hacer ajustes en la seguridad del sistema y para hacer el firmware más eficiente. La eficiencia del código se mide por el número de ciclos de reloj que se necesitan para realizar una tarea o hilo específico. Cuanto menos ciclos de reloj para realizar una tarea, más eficiente es el código, lo que acelera la ejecución y generalmente (no siempre) reduce el tamaño del código. Esto es especialmente cierto para los puntos finales basados en sensores de IoT, ya que estas aplicaciones están impulsadas por la interrupción y por lo tanto deben cambiar rápidamente de contexto cada vez que un sensor o periférico genera una interrupción.

Dos factores que afectan a la eficiencia de las aplicaciones de IoT impulsadas por la interrupción son la eficiencia de la arquitectura y la eficiencia del código. Aunque no es práctico cambiar la arquitectura de un microcontrolador en el campo, es práctico y normal actualizar el firmware del microcontrolador para mejorar la eficiencia.

El firmware basado en los sensores casi siempre se basa en la interrupción. Los sensores inteligentes conectados al puerto serie de un microcontrolador pueden generar una interrupción en el microcontrolador para detener la ejecución normal, de modo que el firmware pueda vectorizar una rutina de servicio de interrupción para ese sensor en particular. Esto es más eficiente que los sensores que necesitan ser interrogados periódicamente para determinar si la lectura del sensor tiene nuevos datos que transmitir. La ventaja de una estrategia de sensores impulsados por la interrupción es que el microcontrolador solo gasta ciclos de reloj en la lectura del sensor cuando hay datos útiles que recibir. El sondeo desperdicia ciclos de reloj cuando el firmware tiene que acceder al sensor para leer datos que se descartan porque la lectura del sensor no se ha actualizado.

Con múltiples sensores y tareas vienen múltiples subrutinas y rutinas de interrupción para manejarlas, aumentando el tamaño del código. El código complejo requiere alguna forma de sistema operativo en tiempo real (RTOS) para gestionar todas estas tareas separadas. El RTOS puede ser una simple aplicación de firmware escrita por el ingeniero de software o un producto estándar. El RTOS gestiona las diferentes tareas del firmware para asegurarse de que cada tarea individual comienza y termina dentro del tiempo necesario para que la aplicación funcione correctamente. Si muchas tareas deben ser gestionadas por el RTOS, es beneficioso que la aplicación para las tareas termine en el menor número de ciclos de reloj posible. Esto evita que las diferentes tareas se retrasen entre sí.

Cuando se recibe una interrupción, el tiempo que se tarda en completar la rutina de servicio de la interrupción es principalmente una combinación de tres factores:

1. Los ciclos de relojes necesarios para reconocer la interrupción y comenzar a vectorizar la rutina de servicio de la interrupción. Si la tarea es de menor prioridad que la que está en marcha, se retrasará hasta que se complete la tarea actual. Esto depende de la aplicación.
2. Los ciclos de reloj necesarios para guardar el contexto del estado actual de la CPU y el vector de la rutina de servicio de interrupción. Esto depende de la arquitectura y está fuera del control del ingeniero de software.
3. Los ciclos de relojes necesarios para ejecutar la rutina de servicio de interrupción. Esto depende tanto de la complejidad como de la eficiencia del código escrito por el ingeniero de software.

Cuanto más eficiente sea el firmware, menos probable es que se produzca un conflicto entre las tareas que deben terminar en un determinado período.

Requisitos de memoria para la actualización del firmware flash

Los sistemas que necesitan ser actualizados de manera confiable en el campo requieren el doble de la memoria de programa flash estimada necesaria para la aplicación. Esto se debe a que la memoria flash debe ser lo suficientemente grande como para contener tanto el firmware flash existente como el actualizado. Sin embargo, es común que los sistemas pequeños que se ejecutan solo desde la memoria interna del programa flash detengan la ejecución del código mientras se recibe la actualización del firmware a través de la red. Esto puede ser inaceptable para las aplicaciones de misión crítica y es contrario al objetivo de un firmware eficiente, es decir, ¡el código que se detiene está funcionando con una eficiencia del cero por ciento!

Ejecutar el firmware mientras se actualiza el flash

Un microcontrolador de alto rendimiento que puede ejecutar el firmware mientras actualiza la memoria flash del chip es el microcontrolador PIC32MZ2048EFH144T-I/PH de Microchip Technology (Figura 1). El PIC32MZ2048EFH144T-I/PH se basa en la arquitectura del núcleo de la Clase M del MIPS32 con una unidad de punto flotante (FPU) que apunta a complejos puntos finales de IoT impulsados por la interrupción. Tiene 2 megabytes (Mbytes) de memoria de programa flash y 512 kilobytes (Kbytes) de SRAM. También tiene 160 Kbytes de flash de arranque. El núcleo del PIC32MZ2048EFH144T-I/PH puede funcionar tan rápido como 252 megahercios (MHz) en un rango de temperatura de -40 °C a +85 °C, y a 180 MHz en un rango de temperatura de -40 °C a +125 °C. El voltaje de funcionamiento es de 2.1 a 3.6 voltios.

Tiene nueve temporizadores de captura/comparación de 32 bits para soportar firmware complejo, así como para medir señales externas.

Figura 1: La PIC32MZ2048EFH144T-I/PH de Microchip Technology de 252 MHz se basa en la arquitectura MIPS32 Clase M y tiene una amplia gama de puertos serie para la interfaz con sensores externos. (Fuente de la imagen: Microchip Technology)

Los puertos seriales externos incluyen nueve UARTs y cinco puertos I²C. Hay seis puertos SPI que también soportan la interfaz de audio I²S. Un convertidor analógico-digital (ADC) de 12 bits con 48 entradas puede medir los voltajes de los sensores analógicos de precisión. Con tantos puertos seriales y entradas ADC, el PIC32MZ2048EFH144T-I/PH puede interactuar con muchos sensores externos, lo que lo hace apropiado para los complejos puntos finales de IoT basados en sensores. Dos puertos CAN 2.0b permiten al microcontrolador conectarse en red con redes industriales y automovilísticas que utilizan el protocolo común CAN.

Un puerto Ethernet soporta la red 10/100Base-T. Un controlador USB 2.0 de alta velocidad soporta una interfaz externa para periféricos adicionales o depuración, y también admite USB On-The-Go (OTG).

Cada uno de estos periféricos puede generar una o más interrupciones. Con tantos sensores y fuentes de interrupción, mantener la eficiencia del código se convierte en una necesidad.

Para mejorar la eficiencia, el núcleo de la CPU del MIPS32 Clase M tiene 32 registros de propósito general (GPR) de 32 bits. Esto mejora la eficiencia al reducir los accesos a la memoria externa. Además de las usuales instrucciones claras y fijas de bits, la Clase M también soporta instrucciones de inversión de bits de un solo ciclo. Esto mejora la eficiencia del RTOS al aumentar la eficiencia del manejo de los semáforos. El núcleo también tiene un conducto de instrucciones de cinco etapas que mejora la eficiencia al minimizar los conflictos de acceso a la memoria, lo que da lugar a más instrucciones de un solo ciclo.

El MIPS32 Clase M también tiene siete juegos de registro de sombras GPR. Esto mejora significativamente el rendimiento de la interrupción y el cambio de contexto, eliminando los muchos ciclos de reloj necesarios para guardar los GPR en la pila. Con siete juegos de registro de sombras, el núcleo puede anidar interrupciones y conmutadores de contexto en siete antes de tener que pasar ciclos de reloj guardando los GPR en la pila.

El PIC32MZ2048EFH144T-I/PH tiene dos bancos de 1 Mbyte de memoria flash de programa (PFM), designados Banco PFM 1 y Banco PFM 2. Cada PFM tiene su propia memoria flash de arranque (BFM) designada como BFM Banco 1 y BFM Banco 2. El BFM no necesita ser actualizado durante una actualización del PFM. Tener estos dos bancos de memoria separados tiene múltiples ventajas. Por ejemplo, el microcontrolador soporta arranque dual, así que al encenderlo puede ser configurado para arrancar desde cualquier banco de memoria flash. Esto permite al microcontrolador soportar dos configuraciones de dispositivos diferentes.

Los dos bancos de flash también ofrecen la ventaja añadida de permitir la ejecución del firmware de un banco de flash mientras se actualiza el firmware del otro banco de flash. Microchip se refiere a esto como Live-Update, también conocido como autoprogramación en tiempo de ejecución (RTSP). Cuando el RTSP se inicia en un punto final activo de IoT ejecutando el firmware del banco PFM 1, el firmware se recibe a través de la red en bloques. El método recomendado para administrar las actualizaciones de firmware en una red es almacenar el bloque de nuevo firmware en SRAM. Después de recibir un bloqueo completo, el firmware que se ejecuta del Banco PFM 1 puede iniciar una secuencia de programación de los datos SRAM en el Banco PFM 2. Mientras se programa este firmware, la ejecución del firmware del Banco PFM 1 puede continuar.

Cuando la programación del bloque se completa, el firmware puede solicitar el siguiente bloque de código a través de la red y la secuencia se repite. Esto continúa hasta que el bloque de código en el Banco PFM 2 se complete. Una vez que la programación esté completa, el firmware puede configurar el PIC32MZ2048EFH144T-I/PH en el siguiente reinicio para arrancar desde el BFM Banco 2 y ejecutar el nuevo firmware en el PFM Banco 2 borrando el bit SWAP en el registro de configuración de NVMCON (Figura 2). Si el firmware PIC32MZ2048EFH144T-I/PH debe ser actualizado de nuevo mientras SWAP=0, el firmware puede ejecutarse fuera del Banco PFM 2 mientras se actualiza simultáneamente el Banco PFM 1.

Figura 2: El microcontrolador PIC32MZ2048EFH144T-I/PH tiene dos bancos independientes de PFM. Si SWAP=1, el firmware puede agotarse en el PFM Banco 1 mientras se actualiza el PFM Banco 2. El SWAP=0 permite al microcontrolador arrancar desde el PFM Banco 2. (Fuente de la imagen: Microchip Technology)

El estado del bit SWAP puede cambiarse desde el BFM o el PFM dependiendo de las necesidades del firmware.

Desarrollo de firmware de arranque dual

Para el desarrollo con el microcontrolador PIC32MZ2048EFH144T-I/PH, Microchip Technology proporciona el kit de inicio DM320007 PIC32MZ (Figura 3). Esta placa soporta múltiples puertos seriales usando conectores dedicados así como conectores de cabecera. Un puerto USB Host se utiliza para la depuración, mientras que un puerto USB OTG puede ser utilizado para la aplicación. Un conector USB-a-UART/I²C, cuando se conecta al puerto USB de una PC, crea un puerto COM virtual en una PC anfitriona conectada. Esto permite que la PC anfitriona se comunique con el puerto I²C en el PIC32MZ.

Figura 3: El kit de inicio compacto DM320007 de Microchip Technology apoya el desarrollo y la prueba de aplicaciones USB y Ethernet con el microcontrolador PIC32MZ2048EFH144T-I/PH. Incluye conectores para USB OTG, USB Host, 10/100 Ethernet y UART/I²C. (Fuente de la imagen: Microchip Technology)

Un conector de cabezal de expansión de 40 pines permite el acceso a puertos adicionales I²C, SPI y UART, así como a los pines de E/S de propósito general (GPIO) del PIC32MZ EF. Hay tres pulsadores y tres LED que pueden ser configurados por el firmware.

Conclusión

Los puntos finales de los sensores de IoT en los sistemas críticos están exigiendo mayores requisitos de memoria debido a la mayor complejidad del código. Cuanto más complejo es el código, más necesario es mejorar la eficiencia del firmware para mejorar los tiempos de respuesta del cambio de contexto en el firmware. Seleccionando un microcontrolador que pueda ejecutar eficientemente el código impulsado por la interrupción y que pueda recuperar y actualizar simultáneamente el firmware, los desarrolladores pueden mejorar la fiabilidad de las aplicaciones críticas de IoT sin sacrificar el rendimiento.