Passer au contenu principal
  • mises à jour ota
  • esp32
  • micrologiciel
  • chargeur d’amorçage
  • systèmes embarqués

Mise à jour OTA de l’ESP32 : fonctionnement du retour à la version précédente du micrologiciel A/B

The Boss Factory11 min de lecture

Une mise à jour sans fil ne réécrit généralement pas le micrologiciel qui s’exécute actuellement. L’appareil télécharge une nouvelle image dans la partition d’application inactive, modifie un petit enregistrement d’état d’amorçage, puis laisse le chargeur d’amorçage décider de ce qui s’exécutera après la prochaine réinitialisation.

C’est cette organisation qui permet le retour à la version précédente. Si l’alimentation est coupée pendant le téléchargement, ou si le nouveau micrologiciel plante avant de confirmer sa santé, l’ancienne partition reste disponible et peut redémarrer.

Ce qu’une mise à jour OTA modifie physiquement

La mémoire flash est divisée en régions par la table de partitions de l’appareil ou sa configuration d’amorçage. Une conception à deux partitions réserve de l’espace pour deux images d’application complètes. Une partition contient le micrologiciel en cours d’exécution; l’autre est inactive et disponible pour la prochaine image.

Pendant une mise à jour, l’application en cours d’exécution effectue normalement les opérations suivantes :

  • Se connecte au serveur de mise à jour ou à l’hôte de fichiers local.
  • Vérifie la taille, le format, le hachage, la signature et parfois la politique de version de l’image.
  • Efface les secteurs nécessaires dans la partition d’application inactive.
  • Écrit l’image reçue dans cette partition, par blocs adaptés à la mémoire flash.
  • Vérifie l’image terminée avant de demander au chargeur d’amorçage de l’utiliser.

Le processeur continue d’exécuter l’image actuelle pendant que ces écritures se font ailleurs dans la mémoire flash. L’application active n’est pas écrasée au milieu de sa propre zone d’instructions.

La mémoire flash n’est pas comme la mémoire vive. Une opération d’effacement vide un secteur complet, tandis que la programmation modifie les bits en unités plus petites selon le composant flash et le contrôleur utilisés. Une perte de connexion laisse une image incomplète dans la partition inactive, mais cette image incomplète n’a aucune autorité pour démarrer, à moins que l’état d’amorçage soit modifié incorrectement.

Sur un ESP32 utilisant le schéma de partition OTA d’ESP-IDF, la table de partitions contient généralement les partitions d’application ota_0 et ota_1, ainsi qu’une partition otadata. Les noms et la disposition exacts dépendent de la table de partitions ESP-IDF sélectionnée; une carte ESP32 dotée d’une taille de mémoire flash différente ou d’une table personnalisée peut donc avoir une capacité et des décalages de partitions différents.

La petite zone d’état qui choisit la prochaine partition

Le chargeur d’amorçage ne devine pas quelle partition d’application est la plus récente en analysant chaque octet de la mémoire flash. Il lit une petite zone d’état qui indique la partition à essayer. Dans la conception ESP32 d’ESP-IDF, otadata contient les données de sélection OTA, avec des enregistrements redondants pour tolérer la corruption d’un enregistrement.

Une bibliothèque OTA écrit d’abord le nouveau micrologiciel. Ce n’est qu’une fois l’image complète et ses vérifications réussies que le processus de mise à jour modifie l’état de sélection d’amorçage afin de marquer la nouvelle partition comme étant en attente. Au redémarrage, le chargeur d’amorçage lit cet état et sélectionne la partition en attente.

C’est ce qui permet de récupérer après une mise à jour interrompue. Si l’alimentation est coupée pendant le transfert de l’image, l’ancienne partition demeure la partition sélectionnée et connue comme fonctionnelle. Si l’alimentation est coupée pendant l’écriture de l’enregistrement de sélection, le chargeur d’amorçage peut utiliser l’enregistrement redondant valide ou appliquer une solution de repli selon ses règles. Le comportement exact de récupération dépend du chargeur d’amorçage et de l’environnement logiciel, mais le principe de conception reste le même : les octets du micrologiciel et l’autorité d’amorçage sont deux éléments d’état distincts.

Un marqueur n’est pas une copie complète du micrologiciel. Il s’agit d’une petite instruction destinée au chargeur d’amorçage, qui représente généralement des états comme valide, vérification en attente ou invalide. Traitez ce marqueur comme un enregistrement de validation de transaction. L’image est préparée en premier; le pointeur vers celle-ci est modifié en dernier.

Pourquoi télécharger n’est pas la même chose que valider

Une nouvelle image peut réussir une vérification de hachage tout en échouant comme programme en cours d’exécution. Elle peut utiliser une mauvaise correspondance GPIO, un schéma de configuration incompatible, un pilote de périphérique défectueux ou provoquer une réinitialisation par chien de garde au démarrage. Un téléchargement réussi prouve que les octets sont arrivés intacts. Il ne prouve pas que l’appareil peut fonctionner avec ceux-ci.

C’est pourquoi un flux OTA sécuritaire comporte un démarrage d’essai et une étape de confirmation :

  1. Le micrologiciel actuel télécharge l’image dans la partition inactive.
  2. Le code de mise à jour vérifie le format de l’image, son intégrité et toute signature requise.
  3. Le chargeur d’amorçage marque la nouvelle partition comme étant en attente et redémarre.
  4. Le nouveau micrologiciel démarre et effectue ses premières vérifications de santé.
  5. Ce n’est qu’après la réussite de ces vérifications que le micrologiciel marque sa partition comme valide ou confirmée.
  6. Si le micrologiciel se réinitialise à répétition avant la confirmation, le chargeur d’amorçage revient à la partition valide précédente, lorsque la configuration sélectionnée de retour OTA le permet.

L’appel de confirmation doit avoir lieu après le démarrage des éléments importants. Pour un contrôleur, cela peut comprendre la pile réseau, le bus de capteurs, les pilotes de sortie et la migration de la configuration persistante. Confirmer immédiatement après l’entrée dans main() annule l’objectif du retour à la version précédente, car une défaillance d’initialisation ultérieure semblera être un démarrage sain.

Ne faites pas dépendre la vérification de santé d’un service réseau indisponible, à moins que l’appareil ne puisse pas fonctionner sans ce service. Une panne temporaire du serveur ne devrait pas condamner un micrologiciel dont le chemin de commande local fonctionne. Nous privilégions un autotest local limité dans le temps, suivi d’une vérification réseau si l’accès au réseau fait partie du fonctionnement requis de l’appareil.

Les données persistantes nécessitent leur propre plan de compatibilité. Les deux partitions d’application sont généralement deux images de micrologiciel, et non deux copies du système de fichiers, des données d’étalonnage ou de la partition des réglages. Si la version 2 modifie le format des réglages enregistrés, le nouveau micrologiciel devrait les valider et les migrer d’une façon qui puisse survivre à une réinitialisation. Sinon, l’image de retour pourrait ne plus comprendre les données modifiées.

Les choix qui découlent du mécanisme

Le stockage du micrologiciel A/B consomme de la capacité flash. Deux partitions d’application doivent pouvoir contenir deux images, et le chargeur d’amorçage, la table de partitions, l’état OTA et tout système de fichiers consomment aussi de l’espace. Si l’application est trop volumineuse pour tenir deux fois, une deuxième partition n’est pas disponible sans changer le composant flash, réduire l’espace du système de fichiers ou utiliser une autre architecture de mise à jour.

Pour un appareil qui commande des moteurs, des chaufferettes, des serrures, des pompes ou tout autre matériel dont le démarrage défaillant peut avoir des conséquences, nous choisirions une mise à jour OTA à deux partitions avec retour à la version précédente plutôt qu’une réécriture sur une seule partition. La mémoire flash supplémentaire coûte moins cher que l’accès physique nécessaire pour récupérer un appareil qui a perdu son alimentation pendant une mise à jour.

Une mise à jour sur une seule partition peut convenir à une carte toujours connectée à un programmateur, dotée d’un connecteur de récupération local et qui n’a pas besoin de mises à jour sans intervention. Elle économise de la mémoire et réduit la complexité logicielle. Elle ne constitue pas une solution de rechange sécuritaire au stockage A/B pour un appareil scellé ou inaccessible.

Disposition du micrologicielExigence de mémoire flashRécupération après une interruption du transfertRécupération après un échec d’amorçageUtilisation la plus appropriée
Une seule partition d’applicationLa plus faibleNécessite généralement un chargeur de récupération ou une nouvelle programmationLimitée à moins qu’une autre image existe ailleursAppareils connectés à un établi avec accès physique pour la récupération
Partitions d’application A/BSuffisante pour deux imagesL’ancienne partition reste disponible lorsque la sélection est modifiée en dernierSolide, avec des états en attente et confirmésAppareils installés nécessitant une récupération sans intervention
Partitions A/B avec zone de préparation externeComplexité et stockage système plus élevésSolide, avec une copie de préparation supplémentaireDépend de la prise en charge du chargeur d’amorçage et du chemin de validationGrandes images ou systèmes dotés d’un contrôleur de mise à jour distinct

La solution économique convient lorsque le matériel se trouve sur l’établi et qu’un câble est toujours disponible. Ajouter une deuxième puce flash ou reconcevoir la carte uniquement pour permettre le retour à la version précédente règle un problème que cette configuration règle déjà. Pour un appareil distant, la même économie peut devenir une fausse économie.

Dimensionnez les partitions à partir de la plus grande image signée que vous prévoyez distribuer, et non du binaire actuel. La journalisation de débogage, les bibliothèques de sécurité, les changements au système de fichiers et les nouveaux pilotes ont tendance à augmenter la taille de l’image. Laissez de l’espace pour le chargeur d’amorçage et la zone d’état définis par l’environnement logiciel, puis testez l’image réelle avec la table de partitions avant d’arrêter la disposition de la carte.

Plan de test pratique pour une mise à jour OTA de l’ESP32

Une mise à jour OTA de l’ESP32 devrait être testée comme un système soumis aux pannes d’alimentation, et pas seulement comme une fonction de téléchargement. Testez les étapes où la mémoire flash et l’état d’amorçage peuvent être désynchronisés :

  • Coupez l’alimentation pendant le téléchargement à plusieurs étapes de progression.
  • Coupez l’alimentation une fois l’image terminée, mais avant la modification de l’état de sélection d’amorçage.
  • Coupez l’alimentation pendant le premier démarrage de l’image en attente.
  • Forcez une réinitialisation par chien de garde avant que le micrologiciel se confirme.
  • Corrompez le hachage ou la signature de l’image et vérifiez que l’ancienne partition démarre toujours.
  • Remplissez la partition des réglages avec des données provenant de la version précédente du micrologiciel.
  • Testez une connexion réseau défaillante sans la traiter comme une défaillance du micrologiciel.
  • Enregistrez la partition sélectionnée, la version de l’image, la raison du démarrage et l’état de confirmation dans les diagnostics.

Utilisez un interrupteur d’alimentation contrôlé ou un relais commandé par un banc d’essai plutôt que de débrancher manuellement un câble USB. L’objectif est la reproductibilité : la défaillance doit se produire à une étape connue et le résultat de la récupération doit être observable.

Vérifiez les journaux du chargeur d’amorçage dans la console série pendant le développement. Ils indiquent si l’appareil a sélectionné une image d’usine, une partition OTA, une image en attente ou un chemin de retour à la version précédente. Examinez aussi la table de partitions générée pour la configuration exacte de la carte. Le comportement OTA dépend du chargeur d’amorçage, de la disposition des partitions, de la taille de la mémoire flash et de la version de l’environnement logiciel; le code copié d’un autre projet ESP32 peut donc être incorrect même lorsque la logique de l’application semble familière.

Pour un micrologiciel signé, vérifiez la chaîne complète : signature de l’image, application des règles par le chargeur d’amorçage, politique de version et gestion des clés. Le chiffrement protège la confidentialité dans les configurations prises en charge, mais il ne remplace ni les vérifications d’intégrité ni une conception de retour à la version précédente. Un appareil qui accepte une image authentique, mais incompatible, a tout de même besoin d’une politique de version et de santé.

Questions fréquentes

Une mise à jour OTA peut-elle écraser le micrologiciel en cours d’exécution?

Dans une conception OTA à deux partitions, elle ne devrait pas le faire. La mise à jour écrit dans la partition d’application inactive pendant que l’image actuelle continue de s’exécuter. Un schéma à une seule partition ou un programme de mise à jour personnalisé peut se comporter différemment et nécessite son propre mécanisme de récupération.

Que se passe-t-il si l’alimentation est coupée pendant une mise à jour OTA de l’ESP32?

Si la nouvelle image était écrite dans la partition inactive, l’ancienne partition reste disponible. Le chargeur d’amorçage choisit une partition à partir de la zone d’état OTA, de sorte que l’image incomplète est ignorée, à moins que l’état de sélection ait déjà été modifié. Lorsque le retour ESP-IDF est activé et que la nouvelle image demeure non confirmée, des échecs répétés au démarrage peuvent ramener l’appareil à la partition valide précédente.

Combien de temps le micrologiciel devrait-il attendre avant de se confirmer?

Il n’y a pas de délai universel. Confirmez après la réussite des vérifications de démarrage requises, et non après un nombre arbitraire de secondes. La vérification devrait couvrir le matériel et les services que l’appareil doit fournir, tout en permettant de gérer les situations temporaires, comme une connexion réseau absente, selon les exigences réelles de fonctionnement du produit.

The Boss Factory réalise ce type de travail sur commande dans les domaines de l’électronique et des systèmes intelligents sur mesure ainsi que du développement de logiciels, de sites Web et d’applications; demandez une soumission.

Services associés

Tous les services →

Vous avez un projet en tête?

Dites-nous ce que vous voulez faire fabriquer — nous répondons en 24 à 48 heures.

Demander une soumission

À lire aussi