Comment puis-je faire des mises à jour incrémentielles avec un flash qui ne peut être effacé que par bloc?

Scénario

Je souhaite mettre à jour un appareil IoT à faible coût par voie hertzienne avec un nouveau micrologiciel mettant à jour le ou les microcontrôleurs de l'appareil. La mémoire du microcontrôleur est une mémoire flash de l'ordre de 32k à 128k (chaque cent compte). Cette mémoire bon marché a une limitation majeure: elle ne peut être effacée que par bloc.

Question

Cela signifie-t-il que je ne peux pas effectuer de mises à jour différentielles ( delta )? Dois-je toujours mettre à jour toute la mémoire du contrôleur (ou au moins des parties substantielles)?

Je veux réduire le besoin de tout flasher et risquer de bricker complètement l'appareil autant que possible. Existe-t-il des stratégies lors du flashage des microcontrôleurs dans l'air?

La réponse simple est oui - vous avez besoin de suffisamment de blocs flash pour prendre en charge le bootloader et les images de code A / B si vous voulez une haute fiabilité. Avant d'activer la nouvelle image, vous pouvez écrire le tout, le vérifier et éventuellement réessayer.

Cependant, c'est une stratégie coûteuse / fiable et il y a des choses que vous pouvez faire pour réduire les frais généraux. La prise en charge de bas niveau des mises à jour OTA peut également faire partie du micrologiciel ou du système d'exploitation de l'appareil, vous pouvez donc éviter de rouler vous-même à moins que vous ne vouliez apprendre. Cette fonctionnalité peut être décrite comme FOTA.

Le partitionnement de votre base de code permet des mises à jour incrémentielles, dans le meilleur des cas, le chargeur de démarrage est en mesure de mettre en place la connexion réseau, de télécharger et de vérifier le code sans avoir besoin de code utilisateur de secours. Avec une passerelle locale, la gestion de cette tâche peut être déléguée à partir des points de terminaison à faible coût.

De nombreux appareils ont une petite quantité de flash d'effacement des mots, et même à défaut, vous pouvez généralement définir des bits sans avoir à effacer un bloc entier. Ces fonctionnalités peuvent être utilisées pour manipuler des tables de sauts et assembler du code mis à jour par blocs de tailles de blocs. Même si vous avez initialement prévu un espace de code A / B complet, vous devrez peut-être revenir à un schéma plus complexe lorsque la base de code se développe trop.

Pour clarifier les fonctionnalités qui peuvent être obtenues avec une solution sophistiquée de micrologiciel par voie hertzienne, le chargeur de démarrage et potentiellement une pile de communication principale peuvent rester résidents tandis que l'espace d'application utilisateur restant est flashé à nouveau. Cela ne nécessite aucune surcharge (en particulier si le partitionnement de bloc est doux). Dans le scénario où la pile de communication doit être mise à niveau, la région généralement utilisée pour le code d'application peut être temporairement utilisée pendant le téléchargement et la vérification. Pour y parvenir, il faut un certain support dans le SoC, mais les appareils de 2e et 3e génération conçus dans cet esprit existent déjà.

Je veux réduire le besoin de tout flasher et risquer de bricker complètement l'appareil autant que possible. Existe-t-il des stratégies lors du flashage des microcontrôleurs dans l'air?

Mis à part votre code qui effectue la mise à jour qui serait relativement statique, vous devez conserver deux images dans votre stockage: une image active et une image de sauvegarde. Chaque fois que vous devez mettre à jour, faites-le dans la sauvegarde, puis activez-le. Une fois stable, mettez à jour l'ancienne image active qui devrait maintenant être votre sauvegarde.

Dans cet esprit, vous pouvez utiliser des algorithmes de nivellement de l'usure lors de la mise à jour des deux images. Le code de ces algorithmes peut prendre environ 10 à 15% du stockage total, mais cela en vaut la peine pour prolonger la durée de vie de l'appareil.

La mise à niveau d'usure est généralement gérée par le contrôleur flash, qui utilise un algorithme de mise à niveau d'usure pour déterminer le bloc physique à utiliser à chaque programmation des données. Il existe deux types de nivellement d'usure des disques SSD: dynamiques et statiques. Les niveaux d'effacement dynamique regroupent les blocs effacés et sélectionnent le bloc avec le plus petit nombre d'effacements pour la prochaine écriture.

Le nivellement d'usure statique, d'autre part, sélectionne le bloc cible avec le nombre d'effacement global le plus bas, efface le bloc si nécessaire, écrit de nouvelles données dans le bloc et garantit que les blocs de données statiques sont déplacés lorsque leur nombre d'effacement de bloc est inférieur à un certain seuil. Cette étape supplémentaire de déplacement des données peut ralentir les performances d'écriture en raison des frais généraux sur le contrôleur flash, mais le nivellement d'usure statique est considérablement plus efficace que le nivellement d'usure dynamique pour prolonger la durée de vie des dispositifs à semi-conducteurs.

( Techtarget.com: nivellement d'usure )

Freescale Semiconductor décrit un moyen robuste de mise à niveau du micrologiciel par voie hertzienne pour leurs microcontrôleurs Kinetis .

Il s'appelle: Program Flash Memory Swap .

Systèmes utilisant l'échange de mémoire flash

Dans les appareils avec deux blocs flash internes ou plus qui prennent en charge l'échange, l'adresse de base de la mémoire de chaque bloc flash peut être échangée. L'emplacement d'adresse de chaque bloc flash sera ainsi échangé dans la carte mémoire logique de l'appareil. Après une réinitialisation, le système d'échange de flash intégré sélectionne essentiellement le logiciel à exécuter en fonction de l'emplacement du bloc flash dans la carte de mémoire logique. Cela permet un système de sauvegarde de code avec la facilité de programmation supplémentaire. Vous pouvez exécuter à partir d'un bloc tout en effaçant / programmant l'autre bloc. Sur les appareils Kinetis, le système de swap flash surveille / contrôle toutes les étapes du passage de l'ancienne application à la nouvelle; il existe une assurance supplémentaire de fonctionnement fiable en cas de perte de puissance pendant l'une de ces étapes.

Les avantages

• Facilité de programmation. L'application s'exécute toujours hors du bloc inférieur de la carte mémoire.
• Tolérant aux pertes de puissance.
• Aucun chargeur de démarrage requis. Aucun retard au démarrage de l'application principale.
• Convient bien pour un système d'exploitation multitâche. Temps d'arrêt minimal des applications. Dans un système multitâche, il est possible de continuer à exécuter les tâches principales de l'application pendant que les tâches en arrière-plan sont en cours d'exécution pour mettre à jour la nouvelle copie de l'application.
• Copie de sauvegarde du code. Possibilité de revenir à l'application de travail connue.

Désavantages

• Espace mémoire flash supplémentaire requis pour stocker la copie de sauvegarde.

Vous pouvez mettre à jour des blocs puis les échanger.

Le document lié contient une description détaillée.

Il garantit des mises à niveau plus sûres du micrologiciel, mais comme il nécessite plus de mémoire flash, il coûte certainement plus cher . En outre pas applicable pour tout type de microcontrôleur, seuls ceux qui soutiennent échange blocs flash interne.