Corruzione della memoria flash AVR

Questa domanda è correlata alla deprogrammazione AVR stessa .

Informazioni sul progetto:
abbiamo un prodotto alimentato a batteria che utilizza un ATMEGA644P. L'applicazione funziona in modo permanente in modalità sospensione e si riattiva solo una volta al secondo (RTC) o quando viene attivata una delle due linee di interruzione esterne.

Il dispositivo dispone di un caricatore di avvio piuttosto semplice che sta comunicando tramite UART (utilizzando l'interfaccia IC RS232). Serve solo come metodo pratico per aggiornare il firmware in modo che non sia necessario alcun programmatore ISP hardware. (Il bootloader si aspetta telegrammi di checksum protetti)

I dispositivi sono stati progettati con brown-out interno DISABILITATO perché raddoppia il consumo energetico e la lunga durata della batteria è obbligatoria (immagino che avrebbe dovuto essere utilizzato un rilevamento brown-out esterno - è in corso una riprogettazione).

Problema:
ogni pochi mesi un dispositivo smette di funzionare, NON sono stati eseguiti aggiornamenti del firmware su tali dispositivi. Tuttavia, dopo un ulteriore esame, il contenuto flash di tali dispositivi sembra essere danneggiato. Inoltre, le batterie di alcuni di questi dispositivi erano ancora buone, ma non voglio escludere una sorta di situazione di sottotensione.

Questo è un confronto tra il contenuto flash originale (a sinistra) e il contenuto danneggiato (a destra):

Alcune osservazioni:

• Un blocco danneggiato è sempre costituito da almeno una pagina flash (256 byte) ed è allineato alla pagina. In altre parole: sono interessate solo le pagine intere, non i singoli byte.
• Il contenuto danneggiato legge 0xFF per la maggior parte del tempo, ma può anche contenere alcuni altri valori o essere completamente "casuale".
• La piccola barra sul lato sinistro dell'immagine mostra tutte le aree interessate. Per questo dispositivo, è circa un decimo del contenuto totale del flash.
• Avevamo un dispositivo in cui era interessata solo una singola pagina.

È assolutamente plausibile che una condizione di sottotensione durante la scrittura della memoria flash possa danneggiare i contenuti flash. Tuttavia, ciò significherebbe che alcune istruzioni sensibili al flash devono essere eseguite.

Forse il controller si riavvia in modo casuale a causa di sottotensione e il codice del caricatore di avvio agisce in modo completamente imprevedibile durante questo periodo. Per citare un ragazzo di un altro forum in merito alla sottotensione:

"Non si tratta solo di istruzioni casuali dall'esecuzione di Flash, ma di un periodo di istruzioni casuali (non vi è alcuna garanzia che il codice da Flash venga letto e interpretato correttamente). Insieme a queste altre parti del MCU potrebbe non comportarsi come previsto, compresa la protezione meccanismi ".

Domande:
ritieni che il "comportamento casuale durante la sottotensione e l'esecuzione di alcune istruzioni che modificano i dati nelle pagine flash" - la spiegazione sia valida? In tal caso, perché non vediamo sempre questo tipo di errori solo come causa di alcuni problemi del software (overflow dello stack, puntatori non validi).

Hai altre idee su cosa potrebbe causare questo tipo di corruzione? Questo potrebbe essere causato da EMI / ESD?

Dovresti notare che il flash non è scritto, è cancellato. Un flash cancellato è pieno di 0xFF. I tuoi primi 256 byte vengono completamente cancellati, la tua terza regione di 256 byte viene parzialmente cancellata (hai solo da 0 a 1 bit-bit dai dati corretti a uno danneggiato).

Secondo il foglio dati , questo flash è cancellabile da pagina (di solito lavoro con blocchi di cancellazione più grandi delle pagine). Come visto a pagina 282, Eseguire la cancellazione della pagina tramite SPM è abbastanza semplice.

Potresti essere interessato dalla sezione 23.8.1 (Prevenzione della corruzione del flash):

Un danneggiamento del programma Flash può essere causato da due situazioni in cui la tensione è troppo bassa. Innanzitutto, una sequenza di scrittura regolare su Flash richiede una tensione minima per funzionare correttamente. In secondo luogo, la CPU stessa può eseguire le istruzioni in modo errato, se la tensione di alimentazione per l'esecuzione delle istruzioni è troppo bassa. La corruzione Flash può essere facilmente evitata seguendo questi consigli di progettazione (uno è sufficiente):

1. Se non è necessario un aggiornamento del boot loader nel sistema, programmare i bit di blocco del boot loader per impedire eventuali aggiornamenti del software del boot loader.
2. Mantenere attivo AVR RESET (basso) durante periodi di tensione di alimentazione insufficiente.
   Questo può essere fatto abilitando il Brown-out Detector (BOD) interno se la tensione operativa corrisponde al livello di rilevamento. In caso contrario, è possibile utilizzare un circuito esterno di protezione con ripristino VCC basso. Se si verifica un ripristino mentre è in corso un'operazione di scrittura, l'operazione di scrittura verrà completata a condizione che la tensione di alimentazione sia sufficiente.
3. Mantenere il core AVR in modalità di spegnimento spegnimento durante i periodi di VCC basso. Ciò impedirà alla CPU di tentare di decodificare ed eseguire le istruzioni, proteggendo efficacemente il registro SPMCSR e quindi Flash da scritture involontarie.

Questo è un problema ben noto e colpisce molti microcontrollori (non solo Atmel). L'hardware di controllo della memoria flash corrompe o cancella parte della memoria in condizioni di bassa tensione. La soluzione semplice è abilitare la protezione brown-out.

Ovviamente dovresti sempre abilitare la protezione brown-out sui microcontrollori.

La sottotensione è una causa molto probabile. Ad esempio, una volta ho avuto un progetto in cui un livello di blackout di 1,8 V causava spesso corruzione e queste corruzioni non potevano mai essere riprodotte con un livello di blackout di 3,5 V.

Si noti che più veloce è il processore, più sensibile è ai problemi di sottotensione. Se la riduzione della frequenza della CPU è un'opzione disponibile per te, potrebbe valere la pena provare.

EMC sarà il tuo più grande nemico, se non seguirai le regole principali della progettazione PCB. Ecco i più importanti della mia esperienza: - bloccare i condensatori su qualsiasi IC, indipendentemente da ciò che i produttori ti dicono nei loro fogli dati sugli schemi infernali, metterne almeno uno tra 100pF - 1nF sulle linee elettriche di ciascun IC - condurre aree di terra su ogni strato di PCB il più possibile. Tali aree devono essere contattate attraverso tutti gli strati tramite viali il più spesso possibile, una griglia di 50mil ha un buon valore. Collegare quelle aree al segnale di terra. - Non lasciare mai rame non collegato (flottante, senza segnale collegato) nel PCB. Agisce come un'antenna e inserisce in modo deviante le radiazioni elettromagnetiche sui dispositivi: traccia le tracce che trasportano i segnali dell'orologio il più corto possibile

Ulteriori dettagli sulle richieste dei motori di ricerca come "guida per la progettazione di circuiti stampati a prova di emc"