test flash atmel atmega64a

[obyone]

salve a tutti
utilizzo per lavoro , schede elettroniche per applicazioni "embedded", con a bordo chip atmel della serie atmega.
vorrei sapere se esiste una procedura e del software che tramite programmatore AVRISP mkii ( che posseggo), sia capace di testare efficacemente la memoria flash e di effettuare evntualmente altre operazioni come ad esempio la formattazione della stessa.
Tutto questo naturalmente , staccando la scheda dalle periferiche a cui è collegata , dimenticavo di dire , che le schede non portano onboard il connettore JTAG.
Spero di essere stato chiaro e rimango in attesa
ciao a tutti e grazie.
obyone.

[deluca]

vorrei sapere se esiste una procedura e del software che tramite programmatore AVRISP mkii ( che posseggo), sia capace di testare efficacemente la memoria flash e di effettuare evntualmente altre operazioni come ad esempio la formattazione della stessa.

ciao obyone, e benvenuto al forum.
cosa intendi per testare efficacemente la memoria flash o formattarla?

vuoi leggerla, controllare se è cancellata, confrontarla con il file bin originale..... oppure cosa?
non mi è chiaro quello che chiedi.

[obyone]

ciao deluca,
grazie per il benvenuto e per la rapida risposta.
intendo dire , a proposito della flash, di poter verificare , attraverso dei test (utilizzando il connettore ISP o anche tramite seriale)se ci sono problemi hw ,in quanto avvolte si verificano perdite di dati "inspiegabili" che mi costringono a sostutire la scheda , ma alla fine non conosco il vero motivo del problema . Vorrei poter eseguire un test che metta sotto stress la memoria della mcu , che faccia delle operazioni di scrittura/lettura e verifica approfonditi in modo da mettere in risalto , se ci sono problemi o meno.
spero di essere stato più chiaro.
grazie
obyone.

[deluca]

@obyone
dovresti spiegarmi meglio alcune cose......

in ke tipo di ambiente lavorano le schede?
"perdite di dati" in che senso? sono permanenti, temporanei? si ripristina il codice una volta resettato il fw?

quello che accade è piuttosto strano....
quei fenomeni possono accadere in ambienti nucleari, dove particelle ionizzanti o neutroni, prodotte da acceleratori di particelle o reattori nucleari, possono interferire con gli strati di silicio della flash e ne possono modificare il contenuto binario della cella in modo irreversibile. Altri problemi possono insorgere in presenza di una brutta alimentazione del uC ecc ecc.

spiega

[obyone]

ciao deluca
le schede lavorano in ambiente "normale", nella fash viene memorizzato il firmware che gestisce la logica di funzionamento e i dati che vengono elaborati dinamicamente e sono proprio questi dati che avvolte vengono alterati / persi dalla memoria . Un esempio classico è la perdita del codice di registrazione di una chiave "dallas", che serve ad abilitare /disabilitare l'apparecchiatura. In questo caso ,procedendo con una nuova registrazione , tutto ritorna normale. Però , per adesso , volevo solo acquisire qualche test diagnostico per il mcu , in particolare per la flash . Ti dico pure che quando si verificano problemi di perdita di dati , il firmware non viene minimamente coinvolto, tant'è che non è necessario ricaricarlo .
spero di essere stato piu chiaro , magari in futuro potremo anche discutere delle problematiche che possono nascere dall'utilizzo del microcontroller ,visto che sei un esperto , ma per adesso , come dicevo , vorrei avere un software per la diagnosi della flash, ammesso che ce ne siano .
grazie per l'interessamento
obyone

[deluca]

@obyone
di sicuro le chiavi, durante il processo di registrazione, vengono memorizzate sulla eeprom interna e non sulla flash del micro.
visto che tu perdi proprio quei codici, significa che è la eeprom ad essere corrotta e non la flash, dato dal fatto che il fw continua a girare.
Le microinterruzioni o disturbi EMC sulla alimentazione possono causare tutto ciò.
Devi controllare attraverso l'uso del tuo programmatore ISP l'impostazione dei fuse bits dell' Atmega64a.
In particolare:

- Brown-out detecion enabled
- Brown-out detection level
- Preserve EEPROM memory through the Chip Erase cycle

Puoi usare molti software con quel programmatore per testare/leggere/programmare la memoria e i fuse bits, ma ti consiglio di farlo con avrstudio4...anche se un pò datato.

Cmq, di solito per testare la eeprom si scrive un fw dedicato a fare ciò...
si scrivono e si verificano tutte le locazioni della eeprom.. dopo aver introdotto disturbi nell'alimentazione.

[Leonardo]

@obyone:

Ti aggiungo solamente qualche altra nota fermo restando che la flash difficilmente verrà scritta ma sarà la eeprom:

Per testare la memoria flash puoi semplicemente fare la verifica con l'hex di programmazione tramite Atmel Studio.
Anche la formattazione della flash è possibile sempre tramite lo stesso programma.

Un'ulteriore causa comune di corruzione di dati sulle memorie è la perdita di alimentazione durante la fase di scrittura, che rientra comunque tra i disturbi di alimentazione ma certe volte è proprio l'utente a spegnere il dispositivo nel momento sbagliato.

La memoria (sia flash che eeprom) ha un numero di scritture limitato sotto specifiche condizioni, superando tale valore la corretta operazione non è garantita. Semplicemente puoi memorizzare il numero di scritture effettuate per avere un'idea dello stato di salute della memoria.

Esistono anche altre tecniche, ogni volta che scrivi puoi scrivere due volte uno spazio "sacrificale" che ti darà così indicazione di malfunzionamento prima della corruzione di eventuali altri dati importanti.

[obyone]

grazie per le risposte
in effetti i problemi riscontrati si verificano in circostanze simili e per problemi sulla rete elettrica ( sbalzi di tensione dovuti a stacco e ritorno della rete , o anche alla cattiva abitudine di spegnere l'apparecchiatura a fine giornata...anche se è presente una batteria tampone )A quanto leggo non dovrebbe essere un problema di "flash" ma di "eeprom" che è la memoria dove sono memorizzati i dati di setup e quelli elaborati durante il funzionamento, almeno credo... ed è quello che vorrei capire meglio .
Non mi è ben chiaro il concetto.

Per testare la memoria flash puoi semplicemente fare la verifica con l'hex di programmazione tramite Atmel Studio.
Anche la formattazione della flash è possibile sempre tramite lo stesso programma.

io uso atmel studio4, mi serve per caricare i fw sul uC della scheda tramite programmatore AVRISP mkii, quale procedura dovrei seguire per verificare se le memorie sono ok ? ho qualche lacuna a proposito e spero nel vostro aiuto per colmarla....
grazie

[deluca]

@obyone,
come ti avevo già detto nel precedente replay, con l' avrisp e avrstudio4 devi controllare l'impostazione dei fuse bits dell' Atmega66a:

- Brown-out detecion enabled
- Brown-out detection level
- Preserve EEPROM memory through the Chip Erase cycle.
(come sono impostati)?

Cmq, potrebbe essere il circuito di alimentazione nell'intorno del micro che non va bene.
Potresti postare lo schema elettrico del tuo circuito, così da vedere la tipologia dei regolatori di tensione e la disposizione dei condensatori?
Nella stessa 5Volt sono attaccate altre utenze? periferiche, attuatori, rele ecc?

Dici che l'alimentazione è tamponata con batterie..... come è fatto il circuito?

......................Per poterti aiutare ci devi dare quante + informazioni possibili.....

[Leonardo]

@obyone:

Con AVR Studio 4 puoi eseguire la verifica della EEPROM, devi però disporre di un file .hex che contiene il contenuto della eeprom che è stato scritto e che dovrebbe essere presente sul micro per poter fare il confronto con lo stato della eeprom attuale.

Non utilizzo da tempo AVR Studio 4, con l'ultima versione di Atmel Studio trovi istruzioni qui:
http://www.atmel.com/webdoc/atmelstudio/atmelstudio.AVRStudio.ProgrammingDialog.Introduction.html
http://www.atmel.com/webdoc/atmelstudio/atmelstudio.section.hzu_gbq_kc.html

Se non hai progettato tu stesso la scheda scheda per quanto riguarda i problemi di alimentazione non è banale risolverli in certi casi e occorre attrezzatura specifica anche costosa (oscilloscopi, etc..).

Ad ogni modo come ti ha suggerito Giovanni abilitando il brown-out si può migliorare la situazione, in sostanza se la tensione cala sotto certi valori (definiti da brown-out detection level) che potrebbero portare il micro ad uno stato illegale, manda il micro in reset fino a che non si ristabilisce la tensione corretta. Se il brown-out non è abilitato potrebbe essere una possibile causa (o perlomeno un aggravante) del problema.

Senza schema elettrico però non si può andare molto avanti..

[obyone]

vi ringrazio per i suggerimenti
i fuses sono regolarmente abilitati , come segue:
SPIEN x
EESAVE x
BOOTSIZE Boot Flash size=4096 words Boot address=$7000
BOOTRTS x
CKOPT x
BOODLEVEL Brown-out detection at VCC=4.0 V
BODEN x
Per altri particolari concernenti la circuiteria , non posso andare oltre nella descrizione ,trattandosi di scheda prodotta in azienda non posso divulgare ne immagini ne tantomeno schemi elettrici , che per altro neanche io posseggo.
Una cosa vorrei chiedervi , ma se durante il funzionamento ,interveniene la protezione da BODEN per un abbassamento della tensione sotto il valore di soglia impostato ( 4.0 v), e di conseguenza si genera un segnale di Reset, a farne le spese è La EEPROM ... o sbaglio ?? e visto che i dati che sovente vengono persi risiedono prorio nella EEPROM , questo ne potrebbe spiegare il motivo ... che ne pensate ? se cosi fosse , potrei abbassare il valore del BOODLEVEL portandolo da 4.0 a 2.7.
scusate se mi prolungo , ma cerco di essere quanto più chiaro possibile , trattando di un argomento che conosco poco , ma che vorrei approfondire .
grazie
obyone

[Leonardo]

Ti riporto un paragrafo del datasheet del microcontrollore in oggetto:

Preventing EEPROM Corruption
During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the CPU
and the EEPROM to operate properly. These issues are the same as for board level systems using EEPROM, and
the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First, a regular write
sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute
instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by
enabling the internal Brown-out Detector (BOD). If the detection level of the internal BOD does not match the
needed detection level, an external low VCC Reset Protection circuit can be used. If a reset occurs while a write
operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.

..che lascia poco spazio ai dubbi.

Portando BODLEVEL a 2.7 peggioreresti solamente la situazione in quanto diminuiresti il tempo per completare correttamente la scrittura.

Se vuoi un sistema affidabile potresti modificare il circuito inserendo un (super)cap adeguatamente dimensionato per dare il tempo al micro di finire la scrittura prima che la tensione scenda ad un livello di instabilità.

[deluca]

Per caso..
nella stessa linea di alimentazione 220 che alimenta le schede uC sono collegate luci fluorescenti con tanto di starter e reattore?

[obyone]

ciao deluca

Per caso..
nella stessa linea di alimentazione 220 che alimenta le schede uC sono collegate luci fluorescenti con tanto di starter e reattore?

non è collegato nessun carico di quel genere a valle del collegamento alla rete 220vac.
Mi chiedevo,ma se poi la EEPROM , è cosi sensibile ai disturbi EMC, non capisco perchè il fw non fa uso escusivamente della memoria flash, che sembra più affidabile ! c è qualche controindicazione ??
vi ringrazio ancora per le risposte , ma rispetto al mio quesito originale , circa la possibilità di effettuare test diagnostici del uC , brancolo ancora nel buio...
ciao
obyone

[Leonardo]

Se non ricordo male la flash di quel micro è scrivibile solamente dal bootloader.. si spiega facilmente perché si usa la EEPROM.

Non pensare che la FLASH sia la soluzione, probabilmente ti si corromperebbe anch'essa.
La soluzione è capire cos'è che crea disturbi e corregge la situazione.

Per i test diagnostici c'è poco da fare col programmatore.. verifichi la eeprom con i dati che pensi dovrebbero esserci (file .hex). Se il test fallisce il contenuto è cambiato, altrimenti è integro.

[deluca]

Atmel a proposito dell atmega64a dice che:
si può riscrivere la sua eeprom 100.000 volte, mentre la flash la si può riprogrammare 10.000 volte....
diciamo che ciò è noto e che lo sappiamo tutti benissimo.

Comunque, è possibile scrivere sulla flash usando l'istruzione "Store Program Memory" l' SPM per interderci,
il problema sta nel numero limitato di cicli di scrittura possibili e la necessità di cancellare la pagina associata ogni volta che si decide di scrivere.

[obyone]

Portando BODLEVEL a 2.7 peggioreresti solamente la situazione in quanto diminuiresti il tempo per completare correttamente la scrittura.

mi lascia un po perplesso questa affermazione .
se porto il BODLEVEL a 2.7v ,consento una maggiore escursione al valore della tensione che alimenta il micro ,in caso di problemi ( da 5v a 2.7v variazione di 2.3v ). Quindi se poniamo la tensione si abbassa da 5 a 4.5 , a 4 a,3.5 a 3 , non entra in funzione i BrownOutReset. e di conseguenza i dati nella EEPROM non vengono "azzerati".
Se invece imposto il BODLEVEL a 4.0v , ( variazione di 1v) è piu facile che piccole fluttuazioni della tensione , causano il reset del uC. Non so dove sbaglio nel ragionamento .
un'altra osservazione , quando giunge il segnale di reset alla EEprom , i dati in essa al momento immagazzinati , si azzerano ?? svelatemi questo dilemma , vi sarò grato....
ciao
obyone

[Leonardo]

Il Reset del BOD non azzera i dati nella EEPROM

Supponiamo che ci sia un calo della tensione ad 1v, ad esempio un attuatore che assorbe una corrente impulsiva importante e un'alimentazione non ben dimensionata.

Se il BOD interviene quando è ancora a 4v ha ancora mettiamo 100uS di tempo per ultimare la scrittura (valore inventato). 100uS è il tempo che ha prima che la tensione mettiamo scenda sotto 2.7v (altro valore inventato, devi controllare nel datasheet), sotto a tale tensione il funzionamento del micro e della EEPROM non è garantito.

Se il BOD interviene quando sei già a 2.7v ultima comunque la scrittura se è in corso ma la tensione potrebbe scendere ad un livello tale non da non poterla completare con sicurezza prima che la concluda.

[deluca]

@obyone,
Con alimentazione del uC pari a 5Volt il BOD level va settato a 4 volt.
il BOD a 2.7 volt va bene se si alimenta l'Atmega64a a 3.3 volt.....

Nota molto importante !! l'indirizzo "0" della eeprom non va mai utilizzato... lo dico per esperienza e perchè viene consigliato anche da molte terze parti produttori dei compilatori, non ricordo se lo ammette anche Atmel.

Se il tuo fw utilizza questo indirizzo, sarà difficile eliminare il tuo prb.

[Leonardo]

Una rapida spiegazione sul perché evitare l'indirizzo zero:
http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_eeprom_corruption.html

Anche se il micro in oggetto non sembra essere affetto da questo problema meglio non rischiare..