AVR se déprogrammant

Quelqu'un d'autre a-t-il eu des cas où un AVR a mystérieusement cessé de fonctionner après plusieurs mois, mais sa reprogrammation le ramènerait?

J'exécute un tas d'atmega328 dans le réseau de capteurs sans fil. J'ai maintenant eu 3 fois (en environ un an) quand l'un d'eux vient de cesser de travailler. Je vais y graver à nouveau le programme et il recommencera à fonctionner. Ce n'est pas toujours la même unité, il ne semble donc pas que ce soit une puce défectueuse.

Cela semble être une chose plutôt désastreuse qui empêcherait les gens d'utiliser des AVR, donc c'est évidemment quelque chose à propos de ma situation particulière. Je me demandais simplement si quelqu'un d'autre s'y est heurté et pourrait avoir des conseils.

Je fonctionne à 3,3 V sur les batteries, donc la tension s'affaissera trop bas pour fonctionner une fois tous les deux mois et je dois remplacer les rechargeables. Les modules utilisent le mode veille et la minuterie du chien de garde pour dormir pendant 60 secondes, prendre une lecture, la retransmettre par radio à la station de base, puis de nouveau dormir. Les modules sont compatibles arduino, donc je n'ai pas retourné le bit "ne me laisse pas recréer ce bit".

Utilisez-vous la DBO? Des choses désagréables peuvent parfois se produire si une puce brunit.

Le Brown-Out-Detection est probablement la bonne façon de le faire, mais ...

J'ai eu un seul problème logiciel qui a provoqué des symptômes très similaires, mais beaucoup plus rapidement. Je crois qu'un mauvais C ++ (compilation?) A entraîné une corruption de la pile et la fonction est retournée en dehors du vrai programme, exécutant des instructions aléatoires. Je ne sais pas exactement ce qui s'est passé ensuite, mais la seule façon de le réparer était de reburn le programme (apparemment certaines de ces instructions aléatoires incluaient l'écriture dans la mémoire du programme).

Le bug n'était qu'un destructeur appelé au mauvais moment. Le fait de rendre la variable globale (afin qu'elle ne soit jamais détruite) a résolu le problème. Le problème était très facilement reproductible (il a fallu environ une minute pour se déclencher) et sur une alimentation très régulière. La configuration particulière était Arduino + WaveShield utilisant la bibliothèque WaveHC, mais je pense que cela pourrait arriver à n'importe qui utilisant C ++.

Si vous préférez les langues de bas niveau, j'ai accidentellement fait la même chose dans l'assemblage, mais miraculeusement, cela n'a jamais causé que des problèmes de timing sporadiques: la plupart des instructions font 2 octets de long, mais certaines sont plus longues, et j'ai calculé la distance de saut moi-même et j'ai sauté au milieu d'une instruction de 4 octets. Il s'est réaligné assez rapidement, mais il n'est pas difficile d'imaginer quelque chose comme ça sur un chemin de code rarement utilisé provoquant la folie.

J'ai également vu des condensateurs de découplage Vcc insuffisants / mal placés / manquants provoquer des effets similaires. Avez-vous un découplage local aussi proche que possible du CI? (Le type de céramique 100nF - 1uF est préféré)

Les décharges électrostatiques (ESD) peuvent également entraîner une perte de mémoire des appareils.

Le placement de quelques varistances sur tous les connecteurs externes qui sont exposés peut exposer à ce problème. Je l'ai déjà vu dans certains produits commerciaux basés sur des microcontrôleurs Microchip PIC, ce n'est donc pas inconnu.

Il existe également des varistances pratiques qui font également office de condensateurs de filtrage (de l'ordre de 10 à 150 pF). Consultez ces http://www.tdk.co.jp/tefe02/e9c11_avr.pdf

Ils sont petits, bon marché et protégeront votre appareil. Placez-les aussi près que possible des connecteurs apportant des signaux externes sur la carte et acheminez immédiatement toutes les traces loin des broches du connecteur.