Newsgroup: it.hobby.elettronica.digitale
Titolo: Cause reset

Ciao,
circuitino semplice con ATtiny2313, oscillatore interno, 3 resisteze, 3 
mosfet, 3 led. Pull-up su reset e condensatore da 100 nF sull'alimentazione.
Ogni tanto (questione di minuti) si resetta il micro.
Che io sappia le cause di un reset sono: errore a run-time, watchdog, 
reset esterno e brown-out.
Ho appurato che:
* con il programmatore inserito non vi sono problemi di reset. Quindi 
non è un problema software. Anche se io ero convinto che dopo la 
programmazione le linee del programmatore andassero in alta impedenza...
* non è dovuto al timeout del watchdog: il problema di presenta anche 
disattivandolo completamente
* ho aggiunto sul reset un condensatore da 470 nF e messo un pullup 
potente (1k8) per mangiare via eventuali disturbi.
* non è dovuto all'alimentazione perché lo sto alimentando con un signor 
alimentatore e se escludiamo il PWM il consumo è costante, senza picchi.
Che altro potrei fare?
Marco / iw2nzm

 Che altro potrei fare?
Non c'è per caso un registro che all'avvio coniene il codice dell'ultima 
causa di start/restart ? 

 ha scritto nel 
messaggio news:g6uf6r$hmn$1...@tdi.cu.mi.it...

E' il registro MCUSR.
Analizzandone il contenuto suboto dopo il powerup, sei in grado di 
discriminare la causa dell'ultimo avvio/riavvio. 

 causa di start/restart ?
Oh no!!! Ricominciamo con i fantasmi :(
Dunque... esempio di debug cromatico: a seconda della causa di reset 
all'accensione la tinta del led rgb è diversa :)
Questa la conclusione:
il reset è ripetibile e determinato dal watch-dog quando attivo.
se non è attivo si pianta lì per un po' e poi *sembra* riprendere....
Ho pensato allora a un problema software... no! Troppo facile! Se metto 
il programmatore collegato non fa una piega! Va per ore senza problemi, 
sgrunt!
Cosa diavolo può fare il programmatore se poi si mette in hi-z?
Che sia l'oscillatore (interno) che si blocca? Ma perché? Purtroppo non 
riesco ad accedere ai pin del micro per vedere il clockout...
Uff...
Marco / iw2nzm

riesco ad accedere ai pin del micro per vedere il clockout...
Non mi sembra probabile una cosa del genere, il problema è sulla Vcc o sul
piedino del Reset, che comunque ha un suo pullup interno.
--
ciao
  Stefano

 piedino del Reset, che comunque ha un suo pullup interno.
Però anche con il condensatore sul reset non risolve - per quanto mi 
impedisca poi la programmazione.
Ciao!
Marco / iw2nzm

impedisca poi la programmazione.
Prova a cambiare dispositivo, magari quello è difettoso.
--
ciao
  Stefano

 Prova a cambiare dispositivo, magari quello è difettoso.
Eh no :(
Dovrei rifare tutto quanto! E' messo via nella lampada, montato su uno 
schedino smd fatto in casa... significa buttare e rifare :(
Il problema è comunque legato alla modifica dei registri OCR1A / B, cioè 
non alla scrittura in sé. Scrivere lo stesso valore non dà problemi, 
cambiare il valore senza scriverlo neppure. Cambiarlo e scriverlo causa 
reset.... ora molto ravvicinati.
Ma solo senza connettore di programmazione... quando c'è il 
programmatore attaccato tutto gira perfettamente.
Sigh
Marco / iw2nzm

 Sigh
shhhhh, sembra funzionare :)
Cosa ho fatto?
	Ho cambiato la frequenza dell'oscillatore interno da 8 MHz a 4 MHz
Perché ora (forse) funziona?
	Non ne ho la piů pallida idea
Marco / iw2nzm

 programmatore attaccato tutto gira perfettamente.
A me queste cose sanno tanto di ground bouncing....
ciao
Claudio_F


Non č che per sbaglio hai attivato qualche sorgente di interrupt legata 
a timer/compare che non č gestita?
Se l'ISR non c'č, se usi l'avr-libc, di default viene assegnato al reset!
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 A me queste cose sanno tanto di ground bouncing....
Ovvero?
Marco / iw2nzm

 Se l'ISR non c'è, se usi l'avr-libc, di default viene assegnato al reset!
uhm... l'unico interrupt attivo è l'OCIE0A. E comunque anche ammesso che 
questa fosse la spiegazione non spiega perché funziona con il 
programmatore inserito e perché cambiando la frequenza dell'oscillatore 
interno le cose cambiano.
Marco / iw2nzm

 Che altro potrei fare?
Prova a controllare di avere tutti gli interrupt disabilitati, soprattutto
quelli a priorità più bassa, che è più facile che, se non utilizzati, ti
mandino al reset entry point.
Ricordati che i nuovi interrupt sui livelli dei pin scattano anche se il
pin è in output (ma il23213 mi sa non li ha)
Al limite metti tutte le ISR anche degli interrupt che non credi di usare e
vedi se smette.

 vedi se smette.
Ho risolto abbassando la frequenza dell'osc interno come scritto 
nell'altro ramo.
Boh!?
Marco / iw2nzm

 nell'altro ramo.
Una volta avevo un problema stranissimo.
Il microcontrollore (ATMega64) si resettava random, più spesso quando 
era poco che era accesso.
Cambiando oscillatore (da quarzo a interno) il problema smetteva. Se lo 
raffreddavo velocemente con una bomboletta si resettava di nuovo.
Alla fine sai cos'era?
Avevo per sbaglio attivato un irq con input capture su un timer, il pin 
in questione era messo come ingresso con pullup, ma essendo sconnesso, 
probabilmente a seconda delle condizioni di temperatura e assorbimento 
captava disturbi che lo facevano commutare...


 Boh!?
A meno che tu non abbia un pezzo low power o dannegggiato, mi stupisco.
Ah, ecco, sì, i fusibili dell'oscillatore!
Controlla un po' per benino che oscillatore hai selezionato, quale usi e
quale gli è stato programmato: Faglielo rileggere a mano: non sempre i
fusibili vengono cambiati quando riprogrammi.

 Ovvero?
Immagino avrai gia' googlato. Puo' dipendere dalla geometria del 
collegamento delle masse (nella realta' le piste di massa sono 
induttanze), qualche segnale di potenza impulsivo che ha il ritorno in 
comune con qualcosa del micro....
Oppure qualcosa di flottante come dicevano altri, e il connettore del 
programmatore potrebbe regolarizzare entrambe la cose.
Prova a connettere SOLO la sua massa (quella del programmatore a quella 
del circuito).
ciao
Claudio_F

 programmazione le linee del programmatore andassero in alta impedenza...
Ebbi problemi del genere con un processore che si programmava/debuggava
attraverso un bus JTAG. Un paio di pin "ausiliari" del JTAG (non i quattro
canonici) necessitavano di pull-up su VCC, pena malfunzionamenti
viscidissimi e irrazionali, che guardacaso sparivano con l'emulatore
collegato (che il pull-up invece ce l'aveva dentro).
-- 
emboliaschizoide.splinder.com

Che altro potrei fare?
AtTiny2313 consente il debug attraverso il filo di reset, che viene poi
disabilitato.
Qui spiega il DebugWire:
http://www.atmel.com/dyn/resources/prod_documents/doc2562.pdf
 
Potresti vedere per esempio se il reset è causato da qualche vettore di
interrupt strano o non inizializzato (possibile anche con il C) mettendo un
breakpoint sul Reset e andando poi a vedere sullo stack da dove arriva il
programma.
Con AVR Studio puoi anche vedere se ci sono interrupt attivi e la situazione del
µC quando si resetta.
Naturalmente devi collegare solo il DebugWire sul pin 1 togliendo eventuali
condensatori.
--
ciao
  Stefano

 Boh!?
eeeh?  mah!
a parte le cause gia' esposte, potrebbe essere anche:
overflow_underflow dello stack.
esecuzione di dati (tabella).
esecuzione nella zona non programmata che poi wrappa in 0000 e preleva
il vettore di reset.
e' in asm ?  puoi postarlo senza compromettere parti riservate ?
saluti

 del circuito).
Ormai la lampada è stata consegnata, non al cliente ma alla destinataria :D
Per la prossima vedrò di migliorare!
Marco / iw2nzm

 e' in asm ?  puoi postarlo senza compromettere parti riservate ?
E' in C, se serve posso postare il codice o anche l'asm generato.
Ciao!
Marco / iw2nzm

 condensatori.
Scusa l'ignoranza ma non ho mai usato un debugger sugli AVR. Non credo 
sia possibile fare quello che suggerisci con l'MkII, o mi sbaglio?
Marco / iw2nzm

sia possibile fare quello che suggerisci con l'MkII, o mi sbaglio?
Atmel ha fatto un pò di confusione con gli MKII.
C'è l'AVRISP mkII In-System Programmer:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808
che fa solo da programmatore.
e AVR JTAGICE mkII:
http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=3353
con la JTAG che supporta AvrStudio.
JTAGICE si può adattare ad usare il DebugWire, rispetto ad una jtag completa ha
qualche problema nell'aggiornamento degli I/O veloci, ad esempio se devi
visualizzare lo stato di un timer ti conviene copiarlo in un registro e poi
mettere il breakpoint.
--
ciao
  Stefano

 con la JTAG che supporta AvrStudio.
Che però costa oltre 350 euro + IVA :(
Ecco perché avevo preso il solo programmatore!
Marco / iw2nzm

 E' in C, se serve posso postare il codice o anche l'asm generato.
meglio asm, ma solo come ultima ratio, se non risolvi in HW_layout.
saluti

 meglio asm, ma solo come ultima ratio, se non risolvi in HW_layout.
Ok! Allora prima provo a verificare che non sia un problema di layout. 
Domani rifaccio lo stampato standoci attento e vediamo!
Marco / iw2nzm

 Domani rifaccio lo stampato standoci attento e vediamo!
Bene, forse ho individuato la causa ma non il rimedio. Vediamo di 
ragionarci assieme.
Anzitutto, ho rifatto il PCB - singola faccia - molto semplice:
http://it.tinypic.com/view.php?pic=xaphd5&s=4
Il micro ha un 100 nF tra le alimentazioni e un pull-up sul reset di 
4k7. Sulla destra ci sono i tre mos e le tre resistenze in serie ai led.
Ho scoperto quanto segue:
l'unico modo per far funzionare il circuito è collegare gli 0V (che sono 
il piano di rame) alla *terra*. Se uso un alimentatore isolato non 
funziona o si comporta in maniera completamente imprevedibile. Questo 
anche con i diodi non connessi.
Mettendo a terra gli 0V (tramite l'alimentatore o anche semplicemente 
con la sonda dell'oscilloscopio) tutto gira come un orologio svizzero.
Ciò è alquanto strano, anzichenò! Mai mi è capitata una situazione 
simile. Perché diavolo vuole la connessione a terra?
Ho provato con i 3 alimentatori che uso da 2 anni per collaudare i miei 
circuiti e il risultato è sempre il medesimo...
Qualche idea?
Mi piacerebbe far funzionare anche questo prototipo, sapete com'è... il 
solito regalo :D
Marco / iw2nzm

 Qualche idea?
Scusa se insisto, ma hai controllato i fusibili dell'oscillatore ed
eventuali interrupt, in particolare sul pinchange?

 eventuali interrupt, in particolare sul pinchange?
Dopo la firma trovi il codice.
Ma se con la connessione a terra funziona, come potrebbe se ci fosse un 
problema nel firmware?
Marco / iw2nzm
--
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#define	OCR_R	OCR1A
#define	OCR_B	OCR1B
#define	OCR_G	OCR0A
#define	RMIN	5
#define	GMIN	5
#define	BMIN	5
#define	RINIT	130
#define	GINIT	255
#define	BINIT	50
#define	RMAX	130
#define	GMAX	255
#define	BMAX	180
#define	UP		0
#define	DOWN	1
uint32_t	i;
uint16_t volatile tick = 0;
uint8_t  volatile update = 0;
struct _RGB {
	uint8_t dr;
	uint8_t dg;
	uint8_t db;
	uint8_t sr;
	uint8_t sg;
	uint8_t sb;
	uint8_t r;
	uint8_t g;
	uint8_t b;
} RGB;
ISR(TIMER0_COMPA_vect) {		// 500 us
	if (++tick > 150) {
		tick = 0;
		update = 1;
	}
}
void effect() {
	if (++RGB.sr == 21) {
		RGB.sr = 0;
		if (RGB.dr == UP) {
			if (++RGB.r == RMAX) RGB.dr = DOWN;
		} else {
			if (--RGB.r == RMIN) RGB.dr = UP;
		}
		OCR_R = RGB.r;
	}
	if (++RGB.sg == 29) {
		RGB.sg = 0;
		if (RGB.dg == UP) {
			if (++RGB.g == GMAX) RGB.dg = DOWN;
		} else {
			if (--RGB.g == GMIN) RGB.dg = UP;
		}
		OCR_G = RGB.g;
	}
	if (++RGB.sb == 17) {
		RGB.sb = 0;
		if (RGB.db == UP) {
			if (++RGB.b == BMAX) RGB.db = DOWN;
		} else {
			if (--RGB.b == BMIN) RGB.db = UP;
		}
		OCR_B = RGB.b;
	}
}
int main() {
	PORTB = 0;
	DDRB = 0xFF;
	if (!(MCUSR & 0x08)) {
		RGB.r = RINIT;
		RGB.dr = DOWN;
		RGB.sr = 0;
		RGB.g = GINIT;
		RGB.dg = DOWN;
		RGB.sg = 0;
		RGB.b = BINIT;
		RGB.db = DOWN;
		RGB.sb = 0;
		OCR_R = RINIT;
		OCR_G = GINIT;
		OCR_B = BINIT;
		TCCR0A = _BV(COM0A1) | _BV(WGM00);
		TCCR0B = _BV(CS01);
		TCCR1A = _BV(COM1A1) | _BV(COM1B1) | _BV(WGM10);
		TCCR1B = _BV(CS11);
		TIMSK  = 0;
		wdt_enable(WDTO_500MS );
		for (i = 0; i < 4000000; i++) wdt_reset();
	}
	MCUSR = 0;
	TIMSK  = _BV(OCIE0A);
	sei();
	for (;;) {
		wdt_reset();
		if (update) {
			update = 0;
			effect();
		}
	}
}

solito regalo :D
Prova a concludere prima di dargli il regalo, sennņ c'č il rischio di andare in
bianco...   ;-)
--
ciao
  Stefano

 bianco...   ;-)
In bianco si va di sicuro stavolta :D
Ma vale la pena lo stesso di farle il regalo!
Ciao!
Marco / iw2nzm

 Con la pila funziona.
Rettifico... funziona un po' ma non sempre. Quindi non è attendibile. 
Gli effetti sono gli stessi dell'alimentatore, solo che *a volte* con la 
pila parte...
Ecco, quando non riesco ad accendere un led mi vien voglia di cambiare 
mestiere :(
Uff
Marco / iw2nzm

mestiere :(
Coraggio, io sto lavorando col C++ in questo momento e mi sto chiedendo da un pò
chi me lo ha fatto fare.
--
ciao
  Stefano

 irradiato o di condotto che disturba il micretto.
No, è la prima cosa che ho provato a fare: toccandolo dappertutto, 
rigirandolo, avvicinandogli anche il trasmettitore RF non fa una piega. 
O meglio, continua a comportarsi allo stesso modo.
Marco / iw2nzm

 problema nel firmware?
Basta non leggere attentamente i datasheet ed ignorare i suggerimenti e
qualunque cosa è possibile...

O meglio, continua a comportarsi allo stesso modo.
Devi almeno riuscire a capire se dipende dall'hardware o dal software.
Inizilaizzare tutti i vettori di interrupt con un Reti puņ aiutare a scongiurare
un reset non voluto.
Poi anche tutti i pin non usati debbono essere collegati da qualche parte o
settati come uscita.
--
ciao
  Stefano

 qualunque cosa è possibile...
Ok, ma tecnicamente come può un errore software "risolversi" con una 
connessione a terra?
E' questo che non capisco, non è polemica... solo ottusità mia!
Marco / iw2nzm

 E' questo che non capisco, non è polemica... solo ottusità mia!
Le vie del Signore sono infinite.
Ma meno di quelle dei bachi.

 Texas a 16 bit, o forse qualche AVR, ma solo in lettura?
Se po' fa, se usate WinAVR c'č un'estensione specifica al gcc che poi li 
mette direttamente in una sezione del file elf generato. L'interfaccia č 
fornita dall'avr-libc:
http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html
Se poi usate un programmatore serio come avrdude, con un pizzico di 
magia di Makefile potete definire un target che automagicamente 
programma tutte le memorie del dispositivo (flash, eeprom e fuses).
Ciao!


 settati come uscita.
Giusto. In un caso come questo non mi fiderei neppure dei pull-up
interni...

 Ma vale la pena lo stesso di farle il regalo!
O č tua madre/sorella, o di donne non capisci nulla ;-)

 O è tua madre/sorella, o di donne non capisci nulla ;-)
Probabilmente è la seconda... ma è già sposata :D
Marco / iw2nzm

 programma tutte le memorie del dispositivo (flash, eeprom e fuses).
mmm, ho provato a dichiarare la sezione FUSES nel codice ma 
l'interfaccia dei programmatori tipo mkII supporta questa cosa? Cioč, se 
io li definisco posso aprire la finestra e vedermeli importati per poi 
programmarmeli?
Ciao!
Marco / iw2nzm

 Dopo la firma trovi il codice.
ok ma non essendo asm la visibilita' e' molto limitata.
chi inizializza port A e D ?
chi inizializza lo stack ?
non si azzera la ram ?
chi imposta gli altri vettori int e le relative isr ?
inizializzi 1 sola volta e poi mai piu' ?
se si sporca qualche registro chi lo rimette a posto ?
zoppica o resta inchiodato fino a quando lo spegni ?
in questi casi servono i 3 tasti [ctrl] [alt] [del] (faccina che ride
  ma non troppo).
ci sarebbe anche altro da dire ma il tempo e' poco.
il livello BOR non e' un po' altino ? si puo' avere + margine ?
per la programmazione: AVRISP usa lo stesso protocollo del STK500,
quindi puoi creare un file di testo .bat che fa tutto: si connette al
programmer e verifica le tensioni, apre i file flash ed eeprom,
verifica la signature uP, programma flash+eeprom+fuses e verifica.
i dati fuses li scrivo nel file .bat ma forse possono essere importati
come parametri o come file (mai provato).  se ti serve un campione...
alcuni IDE_compilatori ti permettono di creare una sezione (segmento)
personalizzata con nome e indirizzi a tua scelta; in questa sezione
scrivi nel solito modo dati oppure stringhe; il compilatore produrra' un
file separato del quale potrai scegliere la formattazione (bin): potrai
cosi' generare un file che contiene il valore dei fuses piuttosto che un
testo con avvisi o messaggi o istruzioni di lavoro.
saluti

 testo con avvisi o messaggi o istruzioni di lavoro.
Capito, grazie dell'informazione, non ne ero al corrente.
Ciao!
Marco / iw2nzm

 trovato traccia nei codici visti (scritti da altri).
E hai fatto bene, non la trovo una filosofia giusta. Se per qualche 
motivo si "sporcano" i registri, secondo me si deve cercare ed eliminare 
la causa che gli sporca, non curare i sintomi, perché il bug rimane 
latente. Anche perché cosa significa "rimetterli a posto"? Chi lo deve 
fare, quando, quanto spesso, dove?


 programmarmeli?
Questo non lo so perché non uso Avrstudio. Come già detto io ho un 
target in più nel makefile che lancia un programmatore esterno (avrdude) 
con i parametri giusti.
Lo puoi o lanciare da riga di comando oppure forse anche da dentro 
avrstudio, devi vedere se c'è modo di lanciare il make con un target 
diverso dai classici "all" e "clean".


 con i parametri giusti.
Mi sono accorto che in effetti sono stato poco chiaro. Il termine 
"programmatore" in questo contesto si riferisce al "programma che gira 
su pc che pilota l'interfaccia hardware per programmare la flash dell'avr".


 Ogni tanto (questione di minuti) si resetta il micro.
hai provato con il clock esterno? 

 fare, quando, quanto spesso, dove?
questo lo decidi tu: quanto tempo vuoi che funzioni zoppicando con una 
porta mal configurata, oppure con un timer o una seriale inchiodate ?
avendo la possibilita' di recuperare il 100% della funzionalita' ,
sarebbe un delitto non farlo.
saluti

 l'interfaccia grafica da AVRStudio se ho ben capito.
no, linea o doppioclick sul file .bat o sull' icona (winxp).
saluti

 sarebbe un delitto non farlo.
Avendo dei problemi (hw o sw) che ti fanno cambiare a caso lo stato dei 
registri è un delitto pensare di risolverli in questo modo!
Sperare che riscrivendo un po' le cose a caso il tutto si sistemi è 
un'utopia.
La mia filosofia di sviluppo è semplice: se qualcosa non va il sistema 
deve segnalarlo il prima possibile in modo da poterlo correggere 
velocemente. Devi metterti in condizione di trovare bug velocemente e 
correggerli efficacemente.
Palliativi come riscrivere i registri o mettere delay a caso possono 
solo rallentare la morte che a quel punto sarà molto più dolorosa.


 solo rallentare la morte che a quel punto sarà molto più dolorosa.
delay a caso ?
e questa da dove viene ?
saluti

 correggo il bug
Quanta roba hai progettato che debba finire dall'altra parte del mondo (o
anche solo della via) e la cui sostituzione od anche il solo semplice reset
manuale costi più dell'apparecchio stesso, senza considerare eventuali
danni esterni causati dal malfunzionamento, o "semplicemente" l'essere
considerati fornitori inaffidabili?
Fammi indovinare...

F. Bertolazzi ha scritto nel messaggio:

Per fortuna che ci sono quelli come Francesco Sacchi, non c'e' semplicemente 
niente da indovinare, come non ci vuole molto per capire altro.......


 Per fortuna che ci sono quelli come Francesco Sacchi
E per sfortuna ci sono i cagnetti morphatori che si attaccano alle caviglie
di chi passa e non mollano manco quando prendono dei gran calci in faccia. 
Davvero non sei stato "sverniciato" abbastanza? Non da me, eh.
So che non ti vergogni di nulla, ma dovresti cominciare ad imparare.

 ha scritto nel messaggio 
news:13v4gb98qs8vf.x...@40tude.net...

Non vedo che attinenza ha questo tuo modo di vedere le cose con l'argomento, 
facevo notare che chi dice certe cose ha dimostrato di avere qualita' tu 
invece ......... vuoi insegnare senza che nessuno ti abbia nominato a farlo

 e questa da dove viene ?
E' un'altra pratica comune che viene usata spesso, insieme alle 
riscritture dei registri, "perché non si sa mai".



Diversi apparecchi.
Di alcuni di essi ce ne sono centinaia di migliaia in giro per il 
mondo tuttora funzionanti.
Il fatto è che i bug e i problemi esistono, non si può pensare di 
risolverli tutti prima che l'apparecchio parta in giro per il mondo.
L'unica cosa che si può fare è mettersi in condizione di trovarli e 
risolverli velocemente sia durante lo sviluppo che durante la vita 
operativa.
Per il resto ti rimando alle risposte a lowcost.


 zoppica o resta inchiodato fino a quando lo spegni ?
Perchč mai un registro dovrebbe sporcarsi? Se *si sporca* significa 
che il codice č scritto male, perň il fatto che con la terra 
collegata funzioni tutto a meraviglia a me fa piů pensare a disturbi 
sulla linea che resettano il micro, non ad errori software.
-- 
Document code?  Why do you think they call it "code?"
News 2002 [v 2.08] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 registro, indirizzo ...
Allora puoi pure sbatterlo via un uP del genere... Stai scherzando 
vero?
-- 
The wise person writes bomb-proof code.


sarebbe un delitto non farlo.
Vedo il tuo modo di affrontare i problemi come molto particolare.
Forse i miei progetti sono molto piů complessi dei tuoi, ma la tua logica 
non č assolutamente applicabile.
Un processo che sta funzionando da diversi giorni puň avere le variabili o i 
registri di configurazione delle porte estremamente differenti dai valori di 
default di partenza.
Ammesso che sia possibile che una singola locazione di memoria si sporchi da 
sola e non sotto il ciclo del programma e tu riesca ad accorgertene, vedo 
molto pericoloso l'andare a riscrivere solo quel valore.
Come si č danneggiata quella locazione si potrebbe benissimo essere 
danneggiato anche un pin di uscita, un pin di ingresso (che leggi perciň 
sempre alto o sempre basso), o qualsiasi altra cosa: il difetto č prima da 
correggere nell'hardware, altrimenti rimane latente.
Anche nelle applicazioni mission critical, non si effettua quello che tu 
asserisci: il programma esegue il suo ciclo normalmente, c'č qualche 
controllo in piů, certo, ma se una macchina non funziona il controllo passa 
ad una macchina parallela e la principale č subito scartata perchč 
considerata non affidabile.
Non si va certo a cercare di capire quale sorta di propagazione nel silicio 
potrebbe eventualmente avere causato il guasto.
Questa č ovviamente solo la mia opinione personale, e anche dei miei 18 
colleghi.
Roberto P.

 che il codice è scritto male,
Si puo' sporcare anche per disturbo esterno, magari indirettamente 
disturbo -> salto di fase del clock o di un qualsiasi circuito 
sequenziale interno -> e qualcosa che doveva essere scritto in un modo 
non lo e' piu'.
Ho visto di persona questo caso quando un disturbo (inserzione di un 
trasformatore) ha coinvolto i registri per la scrittura su un display, 
in apparenza continuava tutto a funzionare regolarmante, ma la scrittura 
era corrotta nonostante venisse aggiornata in continuazione.
In un altro caso era diventato inutilizzabile anche il reset hardware 
(che nei micro non e' un comando diretto alle porte interne ma viene 
trattato quasi come un interrupt) e il micro non e' ripartito se non 
staccando l'alimentazione.
ciao
Claudio_F

 Non vedo che attinenza ha questo tuo modo di vedere le cose con l'argomento, 
Non vedo che attinenza ha questo tuo post con l'argomento.
Anzi, non vedo la tua attinenza con questo universo.

 anche solo della via)
Beh, dipende. Se proprio davanti all'azienda ci sono le strisce con tanto
di semaforo pedonale, un approccio del genere potrebbe anche essere
accettabile. :)
-- 
emboliaschizoide.splinder.com

va bene Francesco.  mi sembra inutile andare avanti.
ho cercato, senza polemica e presunzione, di spiegare che:
vi sono regole e metodi che permettono di scrivere FW a prova di guasto.
alcune di esse possono e dovrebbero essere applicate sempre, grazie al
basso impatto sulle risorse e ai buoni risultati che producono.
due di queste sono l' azzeramento iniziale della ram ed il rinfresco
periodico dei registri di configurazione.
vedo pero' che il tono delle tue risposte e' quello polemico di chi non
puo' o non vuole capire.
prima di salutarti, ho una richiesta: dei tuoi apparecchi, quelli da
centinaia di migliaia in giro per il mondo, puoi indicarne uno che io
possa reperire sul mercato e mettere alla prova ?
saluti

 colleghi.
prima di salutarti, ho una domanda facile facile:
  hai un uP embedded con un pin I/O che muove un led :
   il DDR (pin=out) lo scrivi 1 volta sola all' inizio e poi mai piu' ?
saluti, anche ai 18 colleghi.

 Anzi, non vedo la tua attinenza con questo universo.
Caspita la tua e' megalomania ora ti sei sostituito al creatore per poter 
dire queste cose.
P.s. la tua e' fede come quella dei Talebani :) 

 possa reperire sul mercato e mettere alla prova ?
Certamente, mandami pure una mail in privato (togli OohoO), non mi 
sembra corretto nei confronti dei nostri clienti parlare dei loro 
prodotti in pubblico. Non sono però oggetti che costano 2 euro.


 Ogni tanto (questione di minuti) si resetta il micro.
ehm... ho risolto il problema.
La causa era banale come al solito, quando la si sa :(
Era difettoso il PCB! Alcune piste (in particolare quelle di 
programmazione) presentavano micro interruzioni dovute probabilmente 
allo sforzo a cui erano sottoposte durante l'inserzione/rimozione del 
connettore del programmatore.
Faccio notare che la continuità c'era comunque: mi sono accorto del 
difetto quando i pin dell'header hanno iniziato a muoversi...
Rifacendo lo stampato i problemi sono spariti. Ho comunque corretto le 
gravi mancanze che avevo tralasciato (es. inizializzazione dei pin non 
usati e come mi hanno fatto notare su avr-freaks il suffisso UL 
nell'intero lungo letterale del ciclo for).
Per curiosità ho anche lasciato girare un paio d'ore il vecchio firmware 
e non ha dato problemi.
Ora la lampada è qui accesa di un azzurro puffo (in questo momento) e 
aspetta solo di essere consegnata :D
Grazie in ogni caso per l'interessante thread che si è sviluppato!
Marco / iw2nzm

 disturbo -> salto di fase del clock o di un qualsiasi circuito=20
Ma allora siamo da capo. E' quanto abbiamo appurato: sono i disturbi 
ESTERNI a giocare il ruolo di *sporcatori*. Un codice ben scrito non 
sporca da solo i registri o la memoria.
-- 
IBM: Interesting But Mediocre


 intendevo azzerare tutta la ram prima di inizializzare le variabili.
Non serve ASSOLUTAMENTE a nulla. Perchè QUALSIASI cosa ci sia scritto
(zero o valore casuale) alla prima assegnazione della variabile in 
ram (o dei dati) quel valore verrà sovrascritto.
-- 
Satisfaction Guaranteed: We'll send you another copy if it fails.


 periodico dei registri di configurazione.
Non ha alcun senso pratico. E te lo dice un programmatore. Se la 
memoria si sporca č per colpa del software scritto male. 
-- 
Mommy!  The cursor's winking at me!


Marco trapanese ha scritto:
01/08/08
* con il programmatore inserito non vi sono problemi di reset. Quindi 
02/08/08
Ormai la lampada è stata consegnata, non al cliente ma alla destinataria :D
Proverò a rifare il PCB facendo attenzione a questa cosa.
05/08/08
Anzitutto, ho rifatto il PCB - singola faccia - molto semplice:
Ciò è alquanto strano, anzichenò! Mai mi è capitata una situazione 
simile. Perché diavolo vuole la connessione a terra?
Ho provato con i 3 alimentatori che uso da 2 anni per collaudare i miei 
circuiti e il risultato è sempre il medesimo...
07/08/08
Era difettoso il PCB! Alcune piste (in particolare quelle di 
programmazione) presentavano micro interruzioni dovute probabilmente 
allo sforzo a cui erano sottoposte durante l'inserzione/rimozione del 
connettore del programmatore.
Insomma: hai fatto due PCB diversi che si sono immediatamente rotti nello
stesso identico modo, danneggiando le connessioni per programmatore.
Il programmatore non ha fatto una piega, eppure, appena lo staccavi, il
reset, che nei chip più recenti di Atmel non ha reale necessità di alcun
pull-up o condensatore, nonostante avesse un condensatore 50 volte
superiore al raccomandato ed una resistenza un quinto di quella
raccomandata, ti resettava il processore.
Mah. Sono molto, molto, molto perplesso.

   il DDR (pin=out) lo scrivi 1 volta sola all' inizio e poi mai piu' ?
Fare lampeggiare un led, mi sembra una applicazione leggerina....
Tu che fai, prima di utilizzare un pin di ogni tua applicazione vai comunque 
sempre prima a settarlo come ingresso o come uscita ?
E se č un pin di una periferica, es. uart, vai anche ogni volta a 
riconfigurare il baudrate e tutti gli altri parametri ?
Se č un ingresso analogico con ranging del Vref via sw, lo riconfiguri prima 
di ogni lettura ?
Se decidi di adottare questa logica, lo devi fare sempore e con tutti i 
registri (che non sempre non sono ram).
Se lavori con micro di fascia bassa lo potresti anche fare (a meno che 
l'inizializzazione della periferica ti faccia perdere i dati nell'eventuale 
buffer, rischiando cosě di fare + danni).
Su un prodotto di fascia alta, con sistema operativo o un qualsiasi altro 
kernel che gira sotto, ad un certo punto devi fidarti dell'hw (altrimenti ne 
fai un'altro migliore) e concentrarti sul software, inteso per quello che 
deve fare e controllare.
Ci sono ovviamente da mettere tutti i controlli possibili, ma mi sembra che 
tu non abbia fiducia nell'hw che stai utilizzando o nei progettisti che te 
lo hanno realizzato.
Chiudo, perchč siamo da un oň di tempo abnormenente OT.
Ciao
Roberto P.

 Mah. Sono molto, molto, molto perplesso.
Non hai idea di quanto lo sia io.
Ho solo preso atto di quanto ho visto: di *sicuro* il primo PCB (sempre 
quello del 5 agosto) aveva le piste rovinate. Di *sicuro* quest'ultimo 
che ho fatto funziona. I componenti sono gli stessi, ho recuperato anche 
il micro.
Sinceramente nemmeno io ho una spiegazione sensata per far quadrare 
tutti i problemi, ed è questa la cosa che più mi preoccupa (nel senso: 
se c'è qualcos'altro che non è venuto fuori, mi fregherà alla prossima 
occasione).
:(
Marco / iw2nzm

 che te lo hanno realizzato.
quindi la tua risposta e' si ? (1 volta sola)
grazie e saluti

quindi la tua risposta e' si ? (1 volta sola)
Pensavo fosse implicito, comunque si.
In 22 anni (a prtire dai lontani z80) e con svariati progetti alle spalle, 
non ho memoria di un problema che non fosse dovuto ad un errore di 
programmazione o ad un problema hw.
L'hw deve essere idoneo al contesto di utilizzo e il sw deve svolgere il suo 
ciclo.
Ribadisco che problemi creati da eventuali disturbi esterni sono problemi hw 
e non sono certo compito dei programmatori che non possono inventarsi per 
tutte le procedure gli eventuali malfunzionamenti (sempre che l'hw sia 
gestito direttamente, se c'è un kernel intermedio o un qualcosa tipo una 
fpga/cpld in mezzo, hai un bel da inizializzare...)
Ciao.
Roberto P.

 prodotti in pubblico. Non sono però oggetti che costano 2 euro.
fatto: ti ho richiesto una scheda semplice (un rottame) per prove EMC
sicuramente distruttive.
saluti

 saluti
Ciao
