La réponse en bref
Une mise à jour robuste nécessite un chemin défini vers un appareil capable de redémarrer. Avant de développer le transfert, décidez ce qui doit se produire si l’alimentation disparaît pendant l’effacement, l’écriture, la vérification ou l’activation de la nouvelle image.
Distinguer le chargeur système du processus produit
Le chargeur système intégré au STM32 et le chargeur d’un produit ne remplissent pas nécessairement la même fonction. Interfaces et conditions d’entrée dépendent du composant ; ST les décrit dans AN2606. Vérifiez la référence exacte, pas uniquement la famille. STMicroelectronics — AN2606
Un programmateur peut suffire sur un établi tout en devenant inaccessible après installation. Décrivez qui pourra accéder à l’appareil défaillant et quelle liaison restera disponible. Cette situation détermine les besoins réels de récupération et de maintenance.
Calculer la mémoire avant de choisir l’architecture
Comptabilisez chargeur, application, configuration et espace de travail. Prévoyez une marge justifiée pour les évolutions. La possibilité de conserver deux images internes ou la nécessité d’une mémoire externe doit être calculée pour le microcontrôleur retenu.
MCUboot décrit notamment des démarrages d’essai suivis d’une confirmation ou d’un retour à l’image précédente. C’est une architecture possible, pas une propriété automatique de tout projet STM32. Il faut vérifier l’implémentation et ses besoins mémoire. MCUboot — Bootloader design
Activer une image seulement après vérification
Séparez les états : reçue, vérifiée, démarrée pour essai et confirmée. La fin du téléchargement ne doit pas suffire à autoriser le démarrage. Contrôlez la compatibilité matérielle, la taille autorisée, la version et l’intégrité de l’image.
Une somme de contrôle détecte certaines erreurs de transmission, mais ne prouve pas une origine de confiance. Si l’analyse des menaces le demande, prévoyez une vérification cryptographique de signature avec une racine de confiance protégée. Gestion des clés et autorisation des versions font alors partie du produit.
Reproduire les défaillances à plusieurs étapes
Coupez l’alimentation à différents moments de la procédure et enregistrez l’état obtenu au retour. Essayez aussi une image incomplète, une mauvaise identification matérielle et une application qui démarre sans réussir son contrôle de fonctionnement.
Un critère de réception peut être : après chaque interruption définie, l’ancienne version approuvée démarre ou une procédure documentée de récupération reste accessible. La possibilité d’un redémarrage automatique dépend de la fonction de l’appareil ; elle ne convient pas par défaut à tous les produits.
À inclure dans le plan de mise à jour
- Référence du MCU, révision matérielle et budget mémoire.
- Chemin de récupération accessible et conditions d’utilisation.
- États de l’image et règles de confirmation du démarrage.
- Migration des données de configuration entre versions.
- Résultats des coupures avec identification des firmwares.
Questions fréquentes
Deux banques Flash suffisent-elles ?
Non. Il faut aussi une séquence correcte, des données d’état cohérentes et une décision de démarrage vérifiée. Les caractéristiques Flash dépendent du composant.
Tous les produits doivent-ils permettre une mise à jour à distance ?
Non. Une interface locale de maintenance peut convenir. Le choix dépend de l’accès, du coût d’arrêt, de la procédure de service et des exigences d’authenticité du firmware.
Sources techniques
Prestation associée