Newsgroup: it.hobby.elettronica.digitale
Titolo: ATMEGA e test CE

Ciao a tutti,
abbiamo sviluppato delle schede basate su ATMEGA ed è giunta l'ora deli test
CE.
Innescando dei disturdi in alimentqazione succede che il micro appare come
morto, i led di cui è provvista non lampeggiano (controllati nel loop
principale).
La cosa che non capisco è che è abilitato il watchdog ma non scatta .. se
premo il pulsantino di reset la scheda riparte.
Qualche suggerimento?
----
SteM

 premo il pulsantino di reset la scheda riparte.
su col morale: se non si rompe e non si resetta, sei gia' messo molto
bene con schema_filtri_layout, il resto si aggiusta col firmware.
la malattia che descrivi e' molto diffusa: pensa a quante volte hai
dovuto spegnere_e_riaccendere un fottuto apparecchio malato o morto per
farlo tornare in vita.
perche' parte bene ?   perche' ha inizializzato correttamente i dati
vitali;   perche' poi muore ?   forse perche' e' stato corrotto uno
dei dati vitali ?
analizzando firmware, si nota che un vizio diffuso tra i programmatori
e' mettere una bella "init" , chiamata una volta sola, e poi
dimenticarsi per sempre di questa parte.
tornando al tuo caso, considera che sono dati vitali tutti i bit di
tutti i registri che, se sporcati, compromettono l' applicazione:
i direction e option register delle port, i control e config register
delle periferiche, i mask register dell' interrupt;  in presenza di
radiodisturbi il core puo' scrivere qualunque cosa in qualsiasi registro
indirizzabile:  i pin di uscita led possono diventare ingressi, i timer
possono fermarsi o cambiare modo o velocita', gli interrupt possono
essere disabilitati o mascherati.
la medicina e' semplice: verificare/rinfrescare regolarmente i dati
vitali;  spesso (port) si possono riscrivere senza problemi;  in certi
casi, per evitare effetti collaterali (tipo perdita di int flag), prima
si verifica e poi solo se necessario si riscrive.
il watchdog non interviene perche' e' rinfrescato nel main, che continua
a girare imperterrito.
saluti e auguri

 si verifica e poi solo se necessario si riscrive.
Ne abbiamo già discusso a lungo. In ogni caso, puoi citare qualche
riferimento tecnico o didattico sulle "best practice" che consigli ?
saluti,
simone.bern

 si verifica e poi solo se necessario si riscrive.
IMHO tale pratica non mi sembra dia grande affidabilità in più... Se 
ti si sporcano i registri, ivi compresi quelli dove magari memorizzi 
cicli di loop, variabili ed altro, il rinfresco con i dati di INIT 
non risolve la cosa, a meno che tu non intenda resettare 
completamente il micro ogni tot...
-- 
IBM: I Broke Mine
News 2002 [v 2.3] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 premo il pulsantino di reset la scheda riparte.
Ci provo, anche se gli elementi a disposizione sono veramente pochi....
1)
Hai abilitato il Brown-out Detection (BODEN) ?
Se č abilitato e la tensione scende sotto al valore prefissato, la 
periferica entra in stato di idle e quando la tensione risale, si resetta e 
riparte.
Se invece l'hai disabilitato (come sembrerebbe) e la tensione scende sotto 
ai valori minimi, non accade nulla, la ram si puň 'sporcare' e possono 
accadere eventi non desiderati (anche se in genere in questo caso interviene 
il watchdog, ma non č detto...).
2)
A che livello hai programmato il safety level del watchdog ?
3)
I disturbi, potrebbero innescare interrupt non gestiti correttamente o non 
previsti, che potrebbero 'turbare' il ciclo principale del programma.
Roberto 

 riferimento tecnico o didattico sulle "best practice" che consigli ?
ma perche', Simone, se non te lo dice una normativa o il signor Ganssle
o il signor Freescale, non ci credi ?  (qui ci vorrebbe una faccina,
ma sono troppo vecchio per queste cose).
se invece credi che abbia detto qualche fesseria, dimmi quale.
saluti e buon anno

 se invece credi che abbia detto qualche fesseria, dimmi quale.
Io prima di intervenire sono curioso di vedere un tuo sorgente scritto 
secondo la tua filosofia. Te lo chiedo perché onestamente non riesco a 
immaginare una possibilità concreta di realizzare quello che proponi.
Ma visto che è il tuo modo di lavorare vuol dire che si può fare: 
potresti per favore postare un pezzo di codice che illustri questa tecnica?
Grazie
Marco

 potesse commettere errori.
Abbiamo un Bertolazzi 2 in area? Andiamo bene... Come lui tendi a 
ricordare male o a non capire del tutto gli interventi? Andiamo a 
vedere quel che dicevo riguardo ai tuoi prospettati errori del uC:
http://groups.google.it/group/it.hobby.elettronica.digitale/msg/7ef98a
def170e0a3?hl=it
Il succo era: se si *sporca* la memoria per colpa del codice allora č
meglio imparare a programmare, se invece si *sporca* per colpa di 
disturbi esterni non c'č nessuna soluzione possibile e sensata via 
codice perchč non puoi sapere come, dove e quando i disturbi 
colpiranno... Se sporcano la memoria *proprio* dove tu inizializzi le
variabili che fai? 
Su qualsiasi processore un software scritto BENE NON PUO' COMMETTERE 
ERRORI. Se li commette č per colpa di bug o di disturbi 
particolarmente perniciosi. Pensare che un microprocessore possa 
*commettere errori* cosě, a caso, senza un perchč č assolutamente 
pazzesco e se davvero fosse cosě NESSUNO si azzarderebbe a realizzare
alcunchč con tali arnesi!
-- 
Modem: A deterrent to phone solicitors. 


a domanda precisa ha risposto di inizializzare una sola volta.
Mi sembra che le solite discussioni ritornino ciclicamente quasi per voler 
innescare inutili e gratuite polemiche che nulla hanno a che fare con il 
newsgroup...
Se ritieni di avere fra le mani un hardware o un dispositivo nel quale è 
possibile la corruzione della ram/registri da cause esterne senza che 
intervengano protezioni quali brown-out detection o watchdog: cambialo o 
adotta le opportune contromisure vie hw.
Infatti se sostieni che nei tuoi fw vai ad aggiornare continuamente i dati 
ram/registri (tutti?, nel senso che su una scheda con sistema operativo 
embedded ricarichi continuamente il sistema operativo? Nei controlli 
industriali, con il diffondersi del power over ethernet, queste piattaforme 
sono oggi abbastanza comuni...) e devi essere sicuro che questi valori siano 
assolutamente corretti, significa che li vai a leggere da rom (anche in 
questo caso però, in caso di possibile corruzione, si potrebbero 'sporcare' 
subito dopo essere rinfrescati e prima di essere di fatto utilizzati, 
rendendo inutile il tutto).
Un programma che ha in ram solo valori copiati da rom o che ha impostzioni 
fisse di i/o, in genere serve a poco (...giusto a fare lampeggiare un led a 
frequenza fissa o poco più...).
Se invece hai per le mani una tecnica che consenta di fare sporcare solo le 
locazioni/registri che puoi consentirti e lasciare inalterate altre zone di 
memoria volatile dalle quali prelevare i valori 'corretti' da utilizzare per 
riaggiustare il tutto, ti chiedo di postare un esempio.
L'hw deve essere affidabile, il fw non può fare miracoli (già ha un 
programmatore ha il suo bel da fare per fare andare bene ciò che gli 
compete..).
Se il tuo hw non lo ritieni affidabile, cambialo.
Oppure come nel topic di questa discussione, adotta le opportune 
contromisure hw per evitare che i disturbi condotti si propaghino 
all'elettronica (punti 1 e 2 della mia risposta).
Se in fw ha invece dei bachi che lo fanno entrare in loop con eventi esterni 
(punto 3), occorre verificare il lavoro di programmazione (es il rinfresco 
del wd potrebbe essere stato introdotto in più punti...)
Roberto P. 

 saluti e buon anno
Buon anno a te.
Saluti,
simone.bern

 volentieri.
--------------- estratto da ------------------------------------------
Tim Williams   EMC for Product Designers   2001
Increasingly, electronic equipment of all kinds is becoming more
susceptible to malfunction caused by external interference. This
phenomenon is more and more noticeable ...
The oscillator input pin is high impedance and particularly likely to be
affected. A transient coupled onto this pin will generate a shortened
processor clock period, which is liable to cause a spurious instruction
or data access, thus corrupting the program counter or memory.
Input/output ports connected to long tracks or external connections are
vulnerable on three counts. Small amounts of noise can give spurious
data. Higher levels can corrupt the contents of I/O control or data
registers, while direct ESD can cause CMOS latchup.
Typical software techniques are to: ... • periodically re-initialize
programmable interface chips (PIAs, ACIAs, etc.)
7.2.4.7 Re-initialization
As well as RAM data, you must remember to guard against corruption of
the set-up conditions of programmable devices such as I/O ports or
UARTs. Many programmers assume erroneously that once an internal device
control register has been set up (usually in the initialization routine)
it will stay that way forever. Experience shows that control registers
can change their contents, even though they are not directly connected
to an external bus, as a result of interference. This may have
consequences that are not obvious to the processor: for instance if an
output port is re-programmed as an input, the processor will happily
continue writing data to it oblivious of its ineffectiveness.
The safest course is to periodically re-initialize all critical
registers, perhaps in the main idling routine if one exists. Timers, of
course, cannot be protected in this way. The period between successive
re-initializations depends on how long the software can tolerate a
corrupt register, versus the software overhead associated with the
reinitialization.
--------------- estratto da ------------------------------------------
ATMEL   AVR040: EMC Design Considerations   2006
• Electronic circuits are becoming more and more sensitive.
Power supply voltages are decreasing, reducing the noise margin of input
pins.  Circuit geometries get smaller and smaller, reducing the amount
of energy required to change a logic level, and at the same time
reducing the amount of noise required to alter the logic values of signals.
• The electromagnetic environment is getting tougher.
High-frequency radio transmitters, like mobile telephones, are found
everywhere. More and more systems are using switching power supplies in
the power circuit, and the overall number of electronic appliances is
increasing every year.
--------------- estratto da ------------------------------------------
ZILOG   AN003701 using software techniques to maximize Z8MCU system
noise immunity   2000
...when the main loop completes execution, the system check and refresh
routine runs. ... Refresh includes updating and rewriting ... the I/O
port mode control register, system control register (interrupt and stack
facilities), and timer control register. The purpose of the refresh is
to ensure that any noise-corrupted system control register are
reinitialized to the required state.
--------------- estratto da ------------------------------------------
FREESCALE   AN2764 Improving the Transient Immunity Performance of
Microcontroller-Based Applications   2005
An electrical disturbance that causes enough energy to disrupt digital
logic can also affect the local circuitry that selects the pin function.
The resulting fault could change the pin state, the pin directionality,
or the pin function.
Digital Outputs and Crucial Registers
Within the main system software loop, user software should frequently
update outputs and other critical registers that control output pins.
These include:
• Data direction registers
• I/O modules that can be modified by software
• RAM registers that are used for vital pieces of the application
This ensures that any minor malfunction will be corrected without a
major upset. The refresh of these registers should be as regular as
possible.
--------------- estratto da ------------------------------------------
STM   AN1015 SOFTWARE TECHNIQUES FOR IMPROVING MICROCONTROLLER EMC
PERFORMANCE   2001
EMC-oriented software increases the security and the reliability of your
application. EMC hardened software is inexpensive to implement, it
improves the MCU’s immunity performance and saves hardware costs. You
should consider EMC disturbances to analog or digital data as parameters
that must be managed by the MCU software just like any other application
parameter.
Examples of software disturbances:
– Microcontroller not responding
– Program Counter runaway
– Execution of unexpected instructions
– Bad address pointing
– Bad execution of subroutines
– Parasitic reset
– Parasitic interrupts
– I/O deprogramming
It rarely happens that EMC disturbances alter the content of the
registers. Generally the registers concerned are clock control registers
or I/O configuration and data registers because they are close to the
chip output pads.  In such cases a good security measure is to refresh
these registers frequently.
You can see that good EMC-hardened software can bring the application
immunity to a very high level, limited only by the physical silicon
resistance.
--------------- estratto da ------------------------------------------
STM   AN901 EMC guidelines for microcontroller-based applications   2000
3.2.4 Software Hardening
There are several other methods for improving EMC performances:
...– periodic updating of the control/data registers, which is
particularly useful for the I/O registers which are in the first in line
to face EMI.
----------------------------------------------------------------------
credo sia sufficiente: perdendo un po' di tempo troverai i documenti di
altri costruttori di silicio e gli interventi di Ganssle, Baker ed altri.
saluti e auguri

 rumorosi,
Sě, ma con un servizio di assistenza fatto direttamente o indirettamente
dal progettista, in ambienti, per quanto orrendi, comunque conosciuti e
relativamente immutabili, con hardware surdimensionato tanto il costo non č
un grosso problema, senza utenti che ci fanno, volontariamente o meno, cose
inimmaginabili, insomma, una segreteria telefonica č in un ambiente ben ben
piů ostile.

 potresti per favore postare un pezzo di codice che illustri questa tecnica?
sorry, no;  di postare mio codice (di produzione) ... non ci sento.
se vuoi vedere un esempio semplice, si potrebbe lavorare sul tuo
tiny2313+RGB, oppure, per verificare il risultato, patchare un oggetto
piu' comune che ha mostrato i sintomi della malattia (astenersi telefoni
e fiat auto).
saluti
-- 
  lowcost

 tiny2313+RGB
...dove il problema era hardware, non firmware...
Marco

 nessuna delle sue centomila schede per una prova "live".
E io mi ricordo che la polemica si era chiusa.
Avevamo anche avuto un interessante scambio di mail in privato, in cui 
la situazione si era chiarita.
Per quanto riguarda i miei progetti, visto che fai illazioni, è bene 
che chi legge sappia che come ti ho detto in privato non sono oggetti 
da 2 euro, che io ho solo progettato il firmware per conto di un 
cliente (l'hw lo fanno e producono loro) e che quindi non ho a 
disposizione nessun esemplare perché non seguo la produzione.
Se vuoi puoi acquistare l'apparecchio e fare tutti i test che vuoi, ma 
apparecchi da regalarti non ne ho.
Visto che mi sembra che alla fine il tuo interesse alla discussione 
sia volto alla polemica mi astengo da ulteriori interventi nel thread.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org