AVR deprogrammazione stessa

Qualcun altro ha avuto casi in cui un AVR ha smesso di funzionare misteriosamente dopo diversi mesi, ma riprogrammarlo lo avrebbe riportato?

Sto gestendo un sacco di atmega328 nella rete di sensori wireless. Ora ho avuto 3 volte (in circa un anno) quando uno di loro ha appena smesso di funzionare. Brucerò nuovamente il programma e ricomincerà a funzionare. Non è sempre la stessa unità, quindi non sembra un chip difettoso.

Sembra che sarebbe una cosa piuttosto disastrosa che impedirebbe alle persone di utilizzare gli AVR, quindi è ovviamente qualcosa delle mie circostanze particolari. Mi stavo solo chiedendo se qualcun altro si è imbattuto in esso e potrebbe avere alcuni suggerimenti.

Sto esaurendo le batterie a 3,3 V, quindi la tensione si abbassa troppo per funzionare una volta ogni due mesi e devo sostituire i ricaricabili. I moduli utilizzano la modalità di sospensione e il timer del watchdog per dormire per 60 secondi, prendere una lettura, trasmetterla di nuovo alla stazione base e poi dormire di nuovo. I moduli sono compatibili con Arduino, quindi non ho lanciato il bit "Non farmi ri-masterizzare questo".

Stai usando BOD? Occasionalmente possono succedere cose brutte se un chip si consuma.

Probabilmente il Brown-Out-Detection è il modo giusto di fare, ma ...

Ho avuto un solo problema software che ha causato sintomi molto simili, anche se molto più rapidamente. Credo che un cattivo C ++ (compilazione?) Abbia portato alla corruzione dello stack e la funzione sia tornata al di fuori del programma reale, eseguendo istruzioni casuali. Non sono sicuro di cosa sia successo dopo, ma l'unico modo per risolverlo è stato di ripristinare il programma (apparentemente alcune di quelle istruzioni casuali includevano la scrittura nella memoria del programma).

Il bug era solo un distruttore chiamato al momento sbagliato. Rendere la variabile globale (quindi non è mai stata distrutta) ha risolto il problema. Il problema era facilmente riproducibile (il trigger ha richiesto circa un minuto) e con una potenza molto costante. La configurazione particolare era Arduino + WaveShield che utilizzava la libreria WaveHC, ma penso che ciò possa accadere a chiunque usi C ++.

Se preferisci linguaggi di basso livello, ho fatto accidentalmente la stessa cosa durante il montaggio, ma miracolosamente questo non ha mai causato altro che sporadici problemi di temporizzazione: la maggior parte delle istruzioni sono lunghe 2 byte, ma alcune sono più lunghe, e ho calcolato stupidamente la distanza del salto e ho saltato nel mezzo di un'istruzione di 4 byte. È stato riallineato abbastanza rapidamente, ma non è difficile immaginare qualcosa di simile su un percorso di codice usato raramente che causa follia.

Ho anche visto condensatori di disaccoppiamento Vcc insufficienti / mal posizionati / mancanti che causano effetti simili. Hai il disaccoppiamento locale il più vicino possibile all'IC? (Si preferisce il tipo di ceramica 100nF - 1uF)

Un altro fattore che può causare la perdita della memoria dei dispositivi sono le scariche elettrostatiche (ESD).

Posizionare alcuni varistori su tutti i connettori di rivestimento esterni soggetti a esposizione può alleviare questo problema. L'ho visto prima in alcuni prodotti commerciali basati su microcontrollori PIC Microchip, quindi non è inaudito.

Esistono alcuni varistori utili che fungono anche da condensatori di filtro (nell'ordine di 10-150 pF). Dai un'occhiata a http://www.tdk.co.jp/tefe02/e9c11_avr.pdf

Sono piccoli, economici e proteggeranno il tuo dispositivo. Posizionarli il più vicino possibile ai connettori portando segnali esterni sulla scheda e instradare immediatamente tutte le tracce dai pin del connettore.