Comment effectuer des mises à jour du micrologiciel sans interrompre son exécution

Avec le développement des applications Internet des objets (IoT) basées sur capteurs, la taille et la complexité du micrologiciel des microcontrôleurs augmentent elles aussi au niveau du point d'extrémité IoT. Ce micrologiciel doit devenir plus efficace afin d'accélérer l'exécution. C'est l'une des raisons pour laquelle les mises à jour micrologicielles Flash sur le terrain sont nécessaires. Toutefois, la mise à jour sécuritaire du micrologiciel sur le terrain nécessite généralement d'interrompre son exécution. Selon l'architecture, la taille de la mise à jour et la vitesse du réseau, ce processus de mise à jour peut s'effectuer en à peine une minute ou durer jusqu'à une heure. Pour les applications critiques, un délai trop long est inacceptable.

Cet article aborde les éléments à prendre en compte lors de la mise à jour de micrologiciels commandés par interruption sur le terrain et la nécessité de maintenir l'exécution du micrologiciel d'application pendant le processus de mise à jour. Il présente ensuite le microcontrôleur PIC32MZ2048EFH144T-I/PH de Microchip Technology et montre comment il peut être utilisé pour exécuter le micrologiciel pendant que celui-ci est mis à jour via le réseau.

L'importance des mises à jour micrologicielles

Les micrologiciels sont mis à jour pour quatre raisons principales : corriger les bogues dans le code, ajouter ou améliorer des fonctionnalités, effectuer des ajustements au niveau de la sécurité du système et rendre les micrologiciels plus efficaces. L'efficacité du code est mesurée par le nombre de cycles d'horloge nécessaires pour réaliser une tâche ou un thread spécifique. Moins il y a de cycles d'horloge nécessaires pour effectuer une tâche, plus le code est efficace, ce qui accélère l'exécution et réduit généralement (mais pas toujours) la taille du code. Cela est particulièrement vrai pour les points d'extrémité IoT basés sur des capteurs, car ces applications sont commandées par interruption et doivent donc vite changer de contexte lorsqu'un capteur ou un périphérique génère une interruption.

Deux facteurs affectent le rendement des applications IoT commandées par interruption : l'efficacité de l'architecture et celle du code. Bien qu'il soit impossible de changer l'architecture d'un microcontrôleur sur le terrain, il est possible et normal de mettre à jour le micrologiciel du microcontrôleur afin d'améliorer son efficacité.

Les micrologiciels basés sur des capteurs sont presque toujours commandés par interruption. Des capteurs intelligents connectés au port série d'un microcontrôleur peuvent générer une interruption au niveau du microcontrôleur afin de suspendre l'exécution normale de sorte que le micrologiciel puisse passer à une routine de service d'interruption pour ce capteur précis. Cela est plus efficace que des capteurs qui doivent être périodiquement interrogés pour déterminer si leur lecture indique de nouvelles données à transmettre. L'avantage d'une stratégie de capteurs commandés par interruption est que le microcontrôleur consacre des cycles d'horloge uniquement à la lecture des capteurs qui présentent des données utiles. L'interrogation des capteurs gaspille des cycles d'horloge : le micrologiciel doit accéder au capteur pour lire des données qui sont rejetées, car elles n'ont pas été mises à jour.

Plusieurs capteurs et plusieurs tâches impliquent plusieurs sous-routines et routines d'interruption pour les gérer, ce qui augmente la taille du code. Du code complexe nécessite une certaine forme de système d'exploitation en temps réel (RTOS) pour gérer toutes ces tâches distinctes. Le RTOS peut être une simple application micrologicielle écrite par l'ingénieur logiciel ou un produit prêt à l'emploi. Le RTOS gère les différentes tâches du micrologiciel pour s'assurer que chacune d'elles commence et se termine dans les délais afin de ne pas perturber le bon fonctionnement de l'application. Si de nombreuses tâches doivent être gérées par le RTOS, il est bénéfique pour l'application que celles-ci se terminent en utilisant le moins de cycles d'horloge possible. Cela évite que différentes tâches se retardent mutuellement.

Lorsqu'une interruption est reçue, le temps requis pour effectuer la routine de service d'interruption est principalement une combinaison de trois facteurs :

1. Les cycles d'horloge requis pour reconnaître l'interruption et passer à la routine de service d'interruption. Si la tâche a une priorité moindre que celle en cours, elle est retardée jusqu'à l'achèvement de cette dernière. Cela dépend de l'application.
2. Les cycles d'horloge requis pour enregistrer le contexte de l'état du processeur actuel et passer à la routine de service d'interruption. Cela dépend de l'architecture et est hors du contrôle de l'ingénieur logiciel.
3. Les cycles d'horloge requis pour exécuter la routine de service d'interruption. Cela dépend à la fois de la complexité et de l'efficacité du code écrit par l'ingénieur logiciel.

Plus le micrologiciel est efficace, moins il y a de conflits entre les tâches à terminer dans un certain délai.

Exigences de mémoire pour les mises à jour micrologicielles Flash

Les systèmes qui doivent être mis à jour de manière fiable sur le terrain nécessitent deux fois plus de mémoire programme Flash que ce qui est nécessaire pour l'application. La mémoire Flash doit en effet être suffisamment importante pour contenir à la fois le micrologiciel Flash existant et le micrologiciel mis à jour. Cependant, il n'est pas rare que les petits systèmes exécutés uniquement à partir d'une mémoire programme Flash interne interrompent l'exécution du code pendant la réception de la mise à jour du micrologiciel via le réseau. Cela peut être inacceptable pour les applications stratégiques et nuit à l'objectif d'efficacité du micrologiciel : du code interrompu présente un rendement de 0 % !

Exécution du micrologiciel pendant la mise à jour Flash

Le microcontrôleur hautes performances PIC32MZ2048EFH144T-I/PH de Microchip Technology peut exécuter le micrologiciel tout en mettant à jour la mémoire Flash intégrée (Figure 1). Le PIC32MZ2048EFH144T-I/PH est basé sur l'architecture de cœur MIPS32 M-Class avec une unité en virgule flottante (FPU) qui cible les points d'extrémité IoT complexes commandés par interruption. Il affiche 2 mégaoctets (Mo) de mémoire programme Flash, 512 kilo-octets (Ko) de SRAM et 160 Ko de mémoire Flash d'amorçage. Le cœur du PIC32MZ2048EFH144T-I/PH peut fonctionner jusqu'à 252 mégahertz (MHz) sur une plage de températures de -40°C à +85°C, et jusqu'à 180 MHz de -40°C à +125°C. La tension de fonctionnement s'étend de 2,1 volts (V) à 3,6 V.

Le microcontrôleur comporte neuf temporisateurs 32 bits de capture/comparaison pour prendre en charge un micrologiciel complexe et mesurer les signaux externes.

Figure 1 : Le microcontrôleur PIC32MZ2048EFH144T-I/PH 252 MHz de Microchip Technology est basé sur l'architecture MIPS32 M-Class et offre un large éventail de ports série pour communiquer avec des capteurs externes. (Source de l'image : Microchip Technology)

Les ports série externes incluent neuf UART et cinq ports I²C. Six ports SPI peuvent aussi prendre en charge l'interface I²S audio. Un convertisseur analogique-numérique (CAN) 12 bits à 48 entrées peut mesurer les tensions de capteurs analogiques de précision. Grâce à ces multiples ports série et entrées CAN, le PIC32MZ2048EFH144T-I/PH peut communiquer avec de nombreux capteurs externes, ce qui en fait un dispositif de choix pour les points d'extrémité IoT complexes basés sur des capteurs. Deux ports CAN 2.0b permettent au microcontrôleur d'être relié à des réseaux industriels et automobiles qui utilisent le protocole CAN classique.

Un port Ethernet prend en charge la mise en réseau 10/100Base-T. Un contrôleur USB 2.0 haute vitesse prend en charge une interface externe pour gérer des périphériques supplémentaires ou le débogage, ainsi que la technologie USB On-The-Go (OTG).

Chacun de ces périphériques peut générer une ou plusieurs interruptions. Avec autant de capteurs et de sources d'interruption, maintenir l'efficacité du code devient une nécessité.

Pour ce faire, le cœur du processeur MIPS32 M-Class possède 32 registres à usage général (GPR) 32 bits. Cela améliore l'efficacité en réduisant les accès à la mémoire externe. En plus des instructions habituelles de définition et d'effacement de bits, le M-Class prend aussi en charge les instructions d'inversion de bits à un cycle. Cela améliore l'efficacité du RTOS en augmentant l'efficacité de gestion du sémaphore. Le cœur possède aussi un pipeline d'instructions à cinq niveaux qui améliore l'efficacité en réduisant les conflits d'accès à la mémoire, ce qui entraîne davantage d'instructions monocycles.

Le MIPS32 M-Class présente aussi sept ensembles de registres GPR fantômes. Cela améliore considérablement les performances d'interruption et le changement de contexte en éliminant les nombreux cycles d'horloge requis pour enregistrer les GPR sur la pile. Avec sept ensembles de registres fantômes, le cœur peut abriter des interruptions et des changements de contexte plus profondément (sept niveaux) avant de consacrer des cycles d'horloge à l'enregistrement des GPR sur la pile.

Le PIC32MZ2048EFH144T-I/PH possède deux blocs de mémoire Flash programme (PFM) de 1 Mo : les blocs PFM 1 et PFM 2 dédiés. Chaque PFM possède sa propre mémoire Flash d'amorçage (BFM) dédiée : bloc BFM 1 et bloc BFM 2. La mémoire BFM n'a pas besoin d'être mise à jour pendant une mise à jour PFM. Le fait d'avoir ces deux blocs de mémoire séparés présente de multiples avantages. Par exemple, le microcontrôleur prend en charge l'amorçage double. Lors de la mise en marche, il peut donc être configuré pour être amorcé depuis l'un ou l'autre des blocs de mémoire Flash. Cela permet au microcontrôleur de prendre en charge deux configurations de dispositif différentes.

Les deux blocs Flash présentent un autre avantage : ils permettent l'exécution du micrologiciel à partir d'un bloc Flash pendant qu'il est mis à jour dans l'autre bloc Flash. Microchip appelle cela la mise à jour en direct (Live-Update), également appelée RTSP (Run-Time Self-Programming). Quand le mode RTSP est initié au niveau d'un point d'extrémité IoT actif exécutant le micrologiciel à partir du bloc PFM 1, le micrologiciel est reçu via le réseau sous forme de blocs. La méthode recommandée pour gérer les mises à jour micrologicielles via un réseau consiste à stocker le bloc du nouveau micrologiciel dans la mémoire SRAM. Après réception d'un bloc complet, le micrologiciel exécuté à partir du bloc PFM 1 peut lancer une séquence de programmation des données SRAM dans le bloc PFM 2. Pendant que ce micrologiciel est en cours de programmation, son exécution à partir du bloc PFM 1 peut se poursuivre.

Une fois la programmation du bloc terminée, le micrologiciel peut demander le bloc de code suivant via le réseau, et la séquence se répète. Cela se poursuit jusqu'à l'achèvement du bloc de code dans le bloc PFM 2. Une fois la programmation effectuée, le micrologiciel peut configurer le PIC32MZ2048EFH144T-I/PH pour qu'il démarre, à la prochaine réinitialisation, à partir du bloc BFM 2 et exécute le nouveau micrologiciel du bloc PFM 2 en effaçant le bit SWAP dans le registre de configuration NVMCON (Figure 2). Si le micrologiciel du PIC32MZ2048EFH144T-I/PH doit de nouveau être mis à jour pendant SWAP = 0, il peut être exécuté à partir du bloc PFM 2 tout en mettant simultanément à jour le bloc PFM 1.

Figure 2 : Le microcontrôleur PIC32MZ2048EFH144T-I/PH possède deux blocs PFM indépendants. Si SWAP = 1, le micrologiciel peut être exécuté à partir du bloc PFM 1 tandis que le bloc PFM 2 est mis à jour. SWAP = 0 (effacement) permet au microcontrôleur d'être amorcé à partir du bloc PFM 2. (Source de l'image : Microchip Technology)

Le statut du bit SWAP peut être modifié à partir de la mémoire BFM ou PFM selon les besoins du micrologiciel.

Développement d'un micrologiciel à double amorçage

Pour le développement avec le microcontrôleur PIC32MZ2048EFH144T-I/PH, Microchip Technology propose le kit de démarrage DM320007 PIC32MZ (Figure 3). Cette carte prend en charge plusieurs ports série grâce à des connecteurs et des embases dédiés. Un port hôte USB est utilisé pour le débogage tandis qu'un port USB OTG peut être utilisé pour l'application. Lorsqu'il est connecté au port USB d'un PC, un connecteur USB vers UART/I²C crée un port COM virtuel sur un PC hôte connecté. Cela permet au PC hôte de communiquer avec le port I²C sur le PIC32MZ.

Figure 3 : Le kit de démarrage compact DM320007 de Microchip Technology prend en charge le développement et le test d'applications USB et Ethernet avec le microcontrôleur PIC32MZ2048EFH144T-I/PH. Il inclut des connecteurs pour USB OTG, hôte USB, Ethernet 10/100 et UART/I²C. (Source de l'image : Microchip Technology)

Une embase d'extension à 40 broches permet d'accéder à des ports I²C, SPI et UART supplémentaires ainsi qu'à des GPIO sur le PIC32MZ EF. Trois boutons-poussoirs et trois LED peuvent être configurés par le micrologiciel.

Conclusion

Les points d'extrémité de capteurs IoT dans les systèmes critiques requièrent des exigences de mémoire supérieures en raison de la complexité accrue du code. Plus le code est complexe, plus il est nécessaire d'améliorer l'efficacité du micrologiciel afin d'améliorer les temps de réponse du changement de contexte dans le micrologiciel. En choisissant un microcontrôleur capable d'exécuter efficacement du code commandé par interruption qui peut simultanément récupérer et mettre à jour le micrologiciel, les développeurs peuvent améliorer la fiabilité des applications IoT critiques sans sacrifier les performances.