Altération de la mémoire flash AVR

Cette question est liée à la déprogrammation AVR elle-même .

Informations sur le projet:
Nous avons un produit alimenté par batterie utilisant un ATMEGA644P. L'application fonctionne en permanence en mode veille et ne se réveille qu'une fois par seconde (RTC) ou lorsque l'une des deux lignes d'interruption externes est déclenchée.

L'appareil dispose d'un chargeur de démarrage assez simple qui communique via UART (en utilisant l'interface IC RS232). Il sert simplement de méthode pratique pour mettre à jour le micrologiciel de sorte qu'aucun programmeur ISP matériel ne soit requis. (Le chargeur de démarrage attend des télégrammes sécurisés par somme de contrôle)

Les appareils ont été conçus avec une fonction de désactivation interne désactivée car cela double la consommation d'énergie et la longue durée de vie de la batterie est obligatoire (je suppose qu'une détection de panne externe aurait dû être utilisée - une nouvelle conception est en cours).

Problème:
tous les quelques mois, un périphérique cesse de fonctionner, aucune mise à jour du micrologiciel n'a été effectuée sur ces périphériques. Cependant, après un examen plus approfondi, le contenu flash de ces périphériques semble être corrompu. De plus, les batteries de certains de ces appareils étaient toujours bonnes, mais je ne veux pas exclure une sorte de situation de sous-tension.

Voici une comparaison du contenu flash d'origine (à gauche) avec le contenu corrompu (à droite):

Quelques observations:

• Un bloc corrompu se compose toujours d'au moins une page flash (256 octets) et est aligné sur la page. En d'autres termes: seules les pages entières sont concernées, pas les octets uniques.
• Le contenu corrompu lit 0xFF la plupart du temps, mais peut également contenir d'autres valeurs ou être complètement "aléatoire".
• La petite barre sur le côté gauche de l'image montre toutes les zones affectées. Pour cet appareil, son environ un dixième du contenu total du flash.
• Nous avions un appareil sur lequel une seule page était affectée.

Il est totalement plausible qu'une condition de sous-tension lors de l'écriture de la mémoire flash puisse corrompre le contenu du flash. Cependant, cela signifierait que certaines instructions sensibles au flash doivent être exécutées.

Peut-être que le contrôleur redémarre de manière aléatoire en raison d'une sous-tension et que le code du chargeur de démarrage agit de manière totalement imprévisible pendant ce temps. Pour citer un gars d'un autre forum concernant la sous-tension:

"Ce n'est pas seulement des instructions aléatoires du flash qui sont exécutées, mais une période d'instructions aléatoires (il n'y a aucune garantie que le code du flash sera lu et interprété correctement). Parallèlement à cela, d'autres parties du mcu peuvent ne pas se comporter comme prévu, y compris la protection mécanismes. "

Question (s):
Pensez-vous que le "comportement aléatoire pendant la sous-tension et l'exécution de certaines instructions modifiant les données dans les pages flash" - l'explication est bonne? Si tel est le cas, pourquoi ne voyons-nous pas ce type d'erreurs tout le temps comme une cause de certains problèmes logiciels (débordement de pile, pointeurs invalides).

Avez-vous d'autres idées sur ce qui pourrait provoquer ce type de corruption? Cela pourrait-il être causé par EMI / ESD?

Vous devriez remarquer que le flash n'est pas écrit, il est effacé. Un flash effacé est plein de 0xFF. Vos 256 premiers octets sont totalement effacés, votre troisième région de 256 octets est partiellement effacée (vous n'avez que 0 à 1 bitflips des données correctes aux données corrompues).

Selon la fiche technique , ce flash est effaçable par page (je travaille généralement avec des blocs d'effacement plus gros que les pages). Comme indiqué à la page 282, l'exécution de l'effacement de page par SPM est assez simple.

Vous pouvez être intéressé par la section 23.8.1 (Prévention de la corruption de Flash):

Une corruption de programme Flash peut être causée par deux situations lorsque la tension est trop faible. Tout d'abord, une séquence d'écriture régulière sur le Flash nécessite une tension minimale pour fonctionner correctement. Deuxièmement, le CPU lui-même peut exécuter des instructions de manière incorrecte, si la tension d'alimentation pour exécuter les instructions est trop faible. La corruption de Flash peut être facilement évitée en suivant ces recommandations de conception (une est suffisante):

1. S'il n'y a pas besoin d'une mise à jour du chargeur de démarrage dans le système, programmez les bits de verrouillage du chargeur de démarrage pour empêcher toute mise à jour du logiciel du chargeur de démarrage.
2. Gardez l'AVR RESET actif (bas) pendant les périodes de tension d'alimentation insuffisante.
   Cela peut être fait en activant le détecteur de coupure interne (DBO) si la tension de fonctionnement correspond au niveau de détection. Si ce n'est pas le cas, un circuit de protection externe de réinitialisation à faible VCC peut être utilisé. Si une réinitialisation se produit pendant qu'une opération d'écriture est en cours, l'opération d'écriture sera terminée à condition que la tension d'alimentation soit suffisante.
3. Gardez le noyau AVR en mode veille hors tension pendant les périodes de faible VCC. Cela empêchera le processeur de tenter de décoder et d'exécuter des instructions, protégeant efficacement le registre SPMCSR et donc le flash contre les écritures involontaires.

Il s'agit d'un problème bien connu qui affecte de nombreux microcontrôleurs (pas seulement Atmel). Le matériel de contrôle de la mémoire flash corrompt ou efface une partie de la mémoire dans des conditions de basse tension. La solution simple consiste à activer la protection contre le brunissement.

Vous devez toujours activer systématiquement la protection anti-brunissement sur les microcontrôleurs.

La sous-tension est une cause très probable. Par exemple, j'ai déjà eu un projet où un niveau de brunissement de 1,8 V causait fréquemment de la corruption, et ces corruptions ne pouvaient jamais être reproduites avec un niveau de brunissement de 3,5 V.

Notez que plus le processeur s'exécute rapidement, plus il est sensible aux problèmes de sous-tension. Si la réduction de la fréquence du processeur est une option disponible, cela peut valoir la peine d'essayer.

EMC sera votre plus grand ennemi, si l'on ne suit pas les principales règles de conception des PCB. Voici les plus importants de ma propre expérience: - blocage des condensateurs sur n'importe quel circuit intégré, indépendamment de ce que les fabricants vous disent dans leurs fiches techniques sur les schémas infernaux, mettez au moins un entre 100pF - 1nF sur les lignes électriques de chaque circuit intégré - conduisant des zones de masse sur chaque couche de PCB autant que possible. Ces zones doivent être contactées à travers toutes les couches via des vias aussi souvent que possible, une grille de 50 mil est une bonne valeur. Connectez ces zones au signal de masse. - Ne laissez jamais de cuivre non connecté (flottant, aucun signal connecté) dans votre PCB. Il agit comme une antenne et applique de manière dévinatoire un rayonnement électromagnétique sur les appareils - rend les traces transportant les signaux d'horloge aussi courtes que possible

Trouver plus de détails par les requêtes des moteurs de recherche comme "guide pour la conception de circuits imprimés à l'épreuve des emc"