Votre mise à jour OTA a-t-elle de nouveau rendu le dispositif inutilisable ? La mémoire flash de 128 Ko devrait normalement suffire, mais la partition s'avère pleine d'écueils : le bootloader occupe l'espace applicatif, les données du firmware sont perdues en cas de coupure de courant et il n'existe pas de mécanisme de rollback. L'architecture flash à double zone du MSPM0L1117 est précisément conçue pour garantir des mises à jour OTA fiables, mais le manuel officiel ne vous indique jamais comment optimiser la partition pour une capacité de 128 Ko. Cet article, basé sur un projet de production réel, décortique la logique sous-jacente au basculement entre les banques A et B et propose une solution de partition concrète ainsi qu'une conception résiliente aux erreurs de mise à jour.
Analyse de l'architecture flash à double zone du MSPM0L1117
La mémoire Flash de 128 Ko du MSPM0L1117 utilise une architecture physique à double banque ; les banques A et B sont des images miroir l'une de l'autre et prennent en charge le remappage matériel des adresses. L'avantage principal de cette architecture réside dans le fait qu'il n'est pas nécessaire d'interrompre le firmware en cours d'exécution pendant la mise à jour, permettant ainsi une véritable mise à niveau « en cours d'exécution ».
Cartographie physique et mécanisme de protection des banques A/B de 128 Ko
L'espace d'adressage physique à double banque s'étend de 0x0000_0000 à 0x0001_FFFF ; la Banque A occupe fixement les 64 Ko inférieurs (0x0000_0000-0x0000_FFFF), tandis que la Banque B occupe les 64 Ko supérieurs (0x0001_0000-0x0001_FFFF). Le bit BANK_SWAP du registre crucial FLASH_CONF contrôle le basculement du point de vue d'exécution ; après ce basculement, l'adresse 0 telle que perçue par le CPU pointe en réalité vers l'autre banque physique.
Les mécanismes de protection sont organisés en trois niveaux : protection d'effacement/écriture au niveau des secteurs (32 secteurs × 4 Ko), verrouillage en lecture seule au niveau de la banque, et désactivation globale du port de débogage. Lors de la production en série, il est recommandé d'activer le verrouillage BSL (Bootloader Security Level) afin d'empêcher toute lecture illégale des paquets de mise à jour.
Caractéristiques RWW et fenêtre de sécurité des interruptions
La lecture pendant l'écriture permet au CPU d'exécuter du code depuis le banc A tout en écrivant un nouveau firmware dans le banc B. Toutefois, des contraintes essentielles s'appliquent : la lecture et l'écriture ne peuvent pas être effectuées simultanément dans le même banc, et une opération d'effacement bloque tous les accès à ce banc pendant environ 20 ms. Le sous-programme de service d'interruption doit être placé dans le banc actuellement exécuté ; sinon, une erreur de bus est déclenchée.
Conseils pratiques : copiez la table des vecteurs d'interruption critique dans la SRAM, et désactivez les interruptions non essentielles pendant la mise à jour, ne conservant que le chien de garde et le minuteur de timeout de communication.
Stratégie de partitionnement de 128 Ko : solution optimale pour trois types de scénarios
Le partitionnement constitue la première étape décisive de la réussite de la mise à jour OTA. Bien que 128 Ko semblent suffisants, après déduction du chargeur d'amorçage, de la zone de configuration et de la zone de journalisation, l'espace réel disponible pour l'application est souvent réduit à moins de 50 %.
Solution symétrique à deux zones (60 Ko + 60 Ko) : scénario d'OTA classique
Le bootloader de 8 Ko est fixé en haut de la mémoire Flash (0x0001_F000-0x0001_FFFF), les 120 Ko restants étant répartis équitablement. Chaque zone de 60 Ko accueille le code et les données de l'application, tandis que la zone de configuration partagée de 8 Ko stocke le numéro de version, les indicateurs de mise à jour et le compteur de rollback. Cette solution convient aux applications d'une taille inférieure ou égale à 45 Ko nécessitant des mises à jour complètes fréquentes.
| Zone | Plage d'adresses | Taille | Description |
|---|---|---|---|
| Banque A | 0x0000_0000-0x0000_EFFF | 60 Ko | Zone d'exécution ou cible de mise à jour |
| Banque B | 0x0001_0000-0x0001_EFFF | 60 Ko | Zone d'exécution ou cible de mise à jour |
| Zone de configuration | 0x0000_F000-0x0000_F7FF | 2 Ko | Partagée entre les deux banques, protection contre les coupures d'alimentation |
| Bootloader | 0x0001_F000-0x0001_FFFF | 4 Ko | Non évolutif, verrouillage matériel |
Schéma de partitionnement asymétrique (48 Ko + 80 Ko) : application principale + bootloader allégé
Lorsque l'application dépasse 55 Ko, le schéma symétrique devient insuffisant. La mémoire Bank A est réduite à 48 Ko pour servir de zone de sauvegarde du « firmware d'or », tandis que Bank B est étendue à 80 Ko pour héberger l'application principale. Le bootloader est allégé à 4 Ko, ne conservant que les fonctions de communication, de vérification et de commutation ; la mise à jour de l'application suit une approche par paquets différés.
Ce schéma sacrifie la flexibilité du rollback — les anciennes versions dans Bank A sont limitées — mais permet d'accroître de 33 % l'espace disponible pour l'application principale. Il convient aux produits grand public à itération fonctionnelle rapide et à gros volumes d'augmentation par mise à jour.
Conception de la chaîne de mise à jour OTA et implémentation d'une machine à états
Un OTA fiable ne se limite pas à « télécharger puis redémarrer » ; il nécessite une machine à états couvrant l'ensemble du processus ainsi qu'une récupération en cas d'exception.
Machine à états en trois phases : téléchargement - vérification - commutation
Définition des états : IDLE→DOWNLOADING→VERIFYING→READY→SWAPPING→COMMITTED ; en cas de dépassement du délai ou d'erreur à n'importe quelle étape, le système passe en RECOVERY. Conception clé : avant chaque transition d'état, un indicateur est écrit dans la zone de configuration ; après une coupure de courant et un redémarrage, cet indicateur est lu pour restaurer le contexte.
La phase de vérification utilise une double protection CRC-32 + signature : le CRC au niveau de la couche de transmission détecte les erreurs de bits, tandis que RSA-1024 ou HMAC-SHA256 valide l'authenticité de la source du firmware. Le générateur de nombres aléatoires vrais TRNG du MSPM0L1117 fournit une source d'entropie pour la dérivation des clés.
Sécurité en cas de coupure de courant et mécanisme de récupération après interruption d'écriture
Avantage naturel de l'architecture à deux banques : lors de la mise à jour, l'écriture se fait sur la banque non active ; en cas de coupure de courant à tout moment, le démarrage s'effectue toujours depuis la banque d'origine après redémarrage. La seule fenêtre de risque se situe dans les 100 μs suivant l'écriture du bit BANK_SWAP ; il convient alors d'utiliser une FRAM ou EEPROM externe pour sauvegarder le marqueur « le basculement a été initié ».
La reprise après interruption utilise une stratégie « double marqueur + numéro de séquence » : la zone de configuration maintient current_seq et target_seq ; si les deux sont égaux, on est en état stable, sinon on est en cours de commutation. Après la fin de la commutation, le premier démarrage du nouveau banc nécessite une validation explicite, sinon un retour automatique se produit au redémarrage suivant.
Structure à double numéro de version et indicateur de commutation atomique
Le numéro de version est conçu sur 64 bits : les 32 bits hauts représentent la version principale (sémantique), et les 32 bits bas le horodatage de construction. La zone de configuration conserve simultanément active_version et pending_version ; lors d'une commutation, seul pending_version est mis à jour. Une fois le nouveau firmware démarré avec succès, une validation atomique est effectuée — pending est copié dans active — et l'ensemble du processus est ininterrompible.
Détection de firmware illégal et logique de retour automatique
Après le démarrage du nouveau firmware de la banque, un « période d'essai » est activée : l'autotest doit être terminé et le signal de cœur battant transmis via la communication dans la fenêtre de dépassement du watchdog. Si le délai est dépassé sans soumission ou si l'autotest échoue, le chargeur de démarrage efface le drapeau de basculement, forçant un retour à la banque d'origine lors du prochain démarrage à froid. Ce mécanisme bloque les chemins menant à une perte totale du dispositif et isole les défauts au sein d'un seul cycle de démarrage.
Éviter les pièges en pratique : cinq cas fréquents de dépannage
Dans les projets de production, les problèmes suivants se reproduisent régulièrement, consommant d'importantes heures de débogage.
Conflit entre le dépassement du temps d'effacement et le watchdog
L'effacement typique d'un secteur de 4 Ko prend 15 à 25 ms ; si la période du watchdog est fixée à 20 ms, le système peut redémarrer directement pendant l'effacement sans alimenter le watchdog. Solution : prolonger temporairement le watchdog à 100 ms avant l'effacement, ou adopter un mode intermittent consistant à alimenter le watchdog après chaque petite portion effacée. Une solution encore meilleure consiste à répartir la tâche d'effacement sur la boucle principale et à l'exécuter via le crochet d'inactivité du RTOS.
Équilibrage de la durée de vie de la Flash et comptage de l'usure
La mémoire Flash du MSPM0L1117 est spécifiée pour 100 000 cycles d'effacement, mais les mises à jour fréquentes de la zone de configuration constituent un goulot d'étranglement. En pratique : chaque mise à niveau écrit environ 20 fois dans la zone de configuration, ce qui consomme 20 % de la durée de vie après mille mises à niveau. Solution : utiliser un algorithme d'équilibrage d'usure pour la zone de configuration et effectuer des écritures alternées avec une double sauvegarde ; ou connecter une EEPROM I²C externe pour stocker les données soumises à des mises à jour fréquentes.
Liste de contrôle pour la validation et la production en série
Avant la mise en œuvre du projet, les tests limites doivent être réussis, et le déploiement de la version initiale doit être contrôlé lors de la phase de production en série.
Tests limites : écriture à pleine capacité et simulation de coupures de courant anormales
Point de test n° 1 : remplir le banc jusqu'à 100 % de sa capacité (chaque octet différent de 0xFF), puis vérifier que l'effacement, l'écriture et la vérification sont tous réussis. Point de test n° 2 : simuler, via une alimentation programmable, quatre phases — mise sous tension, fonctionnement, effacement et commutation — avec des coupures de courant aléatoires, répéter chaque cycle 1 000 fois et comptabiliser le taux de réussite au démarrage. Objectif : taux de reprise après coupure de courant anormale ≥ 99,9 %.
Processus de programmation en ligne et de déploiement de la version initiale
Lors de la première programmation en ligne, il faut écrire simultanément le bootloader, le firmware initial de la Banque A et le marqueur « Banque A valide ». La Banque B reste effacée (tous les bits à 0xFF) ; lorsque le bootloader détecte qu'une seule banque est valide, il synchronise automatiquement l'image, garantissant dès la sortie d'usine une redondance à deux zones.
Résumé clé
- MSPM0L1117 à mémoire flash double zoneLa capacité de 128 Ko doit être optimisée : la solution symétrique (60+60 Ko) convient aux applications standard, tandis que la solution asymétrique (48+80 Ko) répond aux scénarios de mise à jour différentielle pour les grandes applications.
- La machine d'état doit couvrir tout le chemin allant de DOWNLOADING à COMMITTED ; un marqueur persistant est utilisé à chaque point de transition afin de restaurer le contexte après une coupure de courant.
- La gestion des versions repose sur une conception à double zone et double numéro de série ; le nouveau firmware n'est validé définitivement qu'après réussite des tests, ce qui empêche toute perte de fonctionnalité.
- Les conflits entre le watchdog et les séquences d'effacement constituent des dangers cachés pour la production en série ; il est nécessaire de prévoir une marge de sécurité supérieure à trois fois ou d'adopter une stratégie d'alimentation intermittente du watchdog.
- L'équilibrage d'usure dans la zone de configuration ne doit pas être négligé : des milliers de mises à jour peuvent rapidement atteindre la limite de vie de la mémoire Flash ; il est recommandé d'utiliser une EEPROM externe pour répartir la charge.
Foire aux questions
La mémoire flash double zone de 128 Ko du MSPM0L1117 peut-elle prendre en charge l'exécution simultanée de versions différentes (A/B) ?
Non. Les deux banques fonctionnent de manière mutuellement exclusive : à un instant donné, une seule banque est mappée à l'adresse 0. Le terme « double zone » fait référence à la redondance de stockage, et non à l'exécution concurrente. La commutation de version doit impérativement se faire via le bit BANK_SWAP matériel, ce qui entraîne une réinitialisation du système et une reconstruction du contexte.
Comment gérer les interruptions de communication pendant une mise à jour OTA ?
Interruption pendant la phase de téléchargement : après le déclenchement du minuteur de timeout, le drapeau est effacé, et les données déjà reçues sont conservées en attendant une reprise ou un nouveau téléchargement complet. Interruption pendant la phase de vérification : si la réception est complète, la vérification locale se poursuit ; sinon, on revient à l'état de téléchargement. Interruption pendant la phase de commutation : c'est la situation la plus risquée ; elle dépend d'un drapeau atomique dans la zone de configuration. Après redémarrage, le bootloader détermine si la commutation est terminée ; si ce n'est pas le cas, l'ancien banc est maintenu.
MSPM0L1117SRHBRLe bootloader peut-il se mettre à jour lui-même ?
La zone BSL officielle est verrouillée au niveau matériel et ne permet pas de mise à jour sur site, mais le bootloader personnalisé de l'utilisateur peut être placé dans une zone effaçable. Il est recommandé de figer le chargeur principal de 4 Ko dans la BSL, de confier l'analyse des protocoles complexes à la zone utilisateur, et d'utiliser une table de sauts pour étendre les fonctionnalités, afin d'éviter toute modification des zones protégées.
Comment vérifier que le nouveau firmware ne rendra pas la puce inutilisable avant la commutation ?
Utilisation de la caractéristique RWW : après l'écriture du nouveau firmware dans le Bank B, il est possible de calculer le CRC des instructions à l'adresse d'entrée et de le comparer avec la valeur attendue. Une approche plus rigoureuse consiste à intégrer dans le Bank B une « image de self-test minimale » — un code purement computationnel ne dépendant pas des périphériques — que le bootloader exécute après sa propre vérification avant de procéder au basculement officiel.
Dans le cas d'une capacité de 128 Ko, la mise à jour différentielle est-elle préférable à la mise à jour complète ?
Le volume du paquet différentiel est généralement réduit à 15–30 % de celui de la mise à jour complète, mais il est nécessaire de conserver l'ancienne version en mémoire Flash comme ligne de base. Dans un scénario de 128 Ko, si l'on utilise une partition symétrique, la ligne de base différentielle et la sortie doivent coexister dans un seul Bank, ce qui limite les économies réelles. Dans une solution asymétrique, le Bank A reste fixé comme ligne de base tandis que le Bank B reçoit la sortie différentielle ; dans ce cas, les gains sont significatifs, et il est recommandé d'utiliser cette méthode conjointement avec les algorithmes bsdiff ou MTF.
