Autoreset, questo sconosciuto

Niente da fare... ho ricontrollato e ricontrollato più e più volte. Ho riflashato tutto, dagli Attiny agli Atmega.
Gli Attiny sono andati, partiti, persi.... non so cosa sia successo.
Il condensatore non c'entra niente perché ho provato con un Atmega328 e questo funziona bene... Eppure divento matto!
Capisco il primo Attiny, magari posso aver fatto io inavvertitamente contatto io con qualcosa, ma il secondo era sì sulla stessa breadboard ma era completamente scollegato! Montato e programmato è saltato anche quello. L'unica cosa che mi può venire in mente è che ho messo il 2° Attiny nello STESSO identico punto della breadboard dove ho programmato il primo. Magari è saltata una pista ed ha bruciato anche il secondo?

@Leo ma il tiny risponde ancora correttamente? cioè riesci a leggere signature e fuse?
hai provato a far blinkare il led su un pin diverso ?

leo72:
Niente da fare... ho ricontrollato e ricontrollato più e più volte. Ho riflashato tutto, dagli Attiny agli Atmega.
Gli Attiny sono andati, partiti, persi.... non so cosa sia successo.
Il condensatore non c'entra niente perché ho provato con un Atmega328 e questo funziona bene... Eppure divento matto!
Capisco il primo Attiny, magari posso aver fatto io inavvertitamente contatto io con qualcosa, ma il secondo era sì sulla stessa breadboard ma era completamente scollegato! Montato e programmato è saltato anche quello. L'unica cosa che mi può venire in mente è che ho messo il 2° Attiny nello STESSO identico punto della breadboard dove ho programmato il primo. Magari è saltata una pista ed ha bruciato anche il secondo?

Ma se anche salta una pista (e ci vorrebbe un corto selvaggio con un'alimentazione notevolissima) al più non riesci a collegare correttamente il pin, al massimo potresti brickarlo, certamente non bruciarlo. Se pensi siano brickati non buttarli, mi raccomando... :wink:

EDIT: comunque sia il condensatore lo hai collegato sul reset di Arduino quindi, al di là della prova col 328, non poteva certo essere lui la causa del problema.

menniti:
EDIT: comunque sia il condensatore lo hai collegato sul reset di Arduino quindi, al di là della prova col 328, non poteva certo essere lui la causa del problema.

Esatto, il condensatore non ha alcun punto di contatto col micro che viene programmato, è solo sul pin di reset dell'ATmega sul quale c'è lo sketch isp.

@Brain:
curiosamente sì, riesco a flasharlo sia dall'IDE sia con l'USBtinyISP. In entrambi i casi è visto correttamente e programmato.

@menniti:
nessun "corto selvaggio", alimentavo la breadboard con i 5V presi dall'Arduino e son sicuro di non aver invertito i ponticelli (+ sul - e viceversa) perché uso sempre cavetti colorati (rosso per il + e verde per il -) quindi facilmente identificabili

@astro:
chiaro.

Cmq qualcosa è successo.
Esattamente prima della programmazione il LED sul pin dell'Attiny lampeggiava con un'intensità normale. Appena ho programmato il micro, il LED credevo fosse spento, da quanto era fioco. Ho dovuto parare la luce con la mano per vedere che lampeggiava. Inoltre mi sono accorto che qualcosa non andava perché ho notato che, appena terminata la programmazione ISP, il led "L" sull'Arduino era fiocamente illuminato perché riceveva tensione dall'Attiny mediante il cavettino sul pin 13. Collegando infatti un LED direttamente al 7° pinedino dell'Attiny (pin 2) mi sono accorto che usciva tensione, misurata in 4,8V con un tester.

Resta il mistero che da ieri sera ho i 2 Attiny "andati".

Una considerazione sulle correnti in gioco, osservando attentamente la misura con il condensatore da 10 uf si vede chiaramente che il segnale DTR non va subito a 0 logico, come avviene in tutti gli altri casi, ma ci va in un certo tempo seguendo la curva di carica del condensatore da 100 nf.
La cosa è abbastanza logica perché la corrente che può scorrere nel circuito è limitata dalla somma dell'impedenza d'uscita del FTDI o 8u2, non dichiarate sul data sheet, e dalla ESR del condensatore che normalmente per un elettrolitico da 10 uf, non low esr, è una decina di ohm.
E' possibile stimare con buona precisione la reale corrente che scorre partendo dalla costante di tempo della variazione su DTR, circa 8 us per arrivare al valore di tensione dovuto a RC, con un semplice calcolo ci troviamo la resistenza serie equivalente e da questa la corrente di picco.

R = 8 us / 100 nf = 80 ohm.
Ip = 5V / 80 ohm = 62 mA.

Anche se è un valore di picco che dura meno di un us è superiore alla massima corrente ammessa su un GPIO del 8u2 o del FTDI, nel primo caso sono 40 mA nel secondo caso sono 24 mA.
Da notare che le misure sono state fatte sia su una UNO che su una 2009, sono totalmente identiche salvo l'ultima con il condensatore da 10 uf dove sulla 2009 il tempo di discesa verso lo 0 logico di DTR è maggiore, non mi ricordo di quanto e non ho salvato la misura, il che limita la corrente che passa sul FTDI a molto meno di 62 mA, sicuramente a causa del fatto che l'impedenza d'uscita è maggiore rispetto al 8u2.
Da tenere presente che il valore di corrente massimo sui GPIO riportato sui datasheet è riferito ad un flusso continuo e non ad una serie di impulsi, toccherebbe parlare di valore rms della corrente che ci porta ad un valore continuo equivalente quasi nullo nel nostro caso.
In tutti i casi sarebbe bene non superare lo stesso i valori massimi riportati dai data sheet, per ottenere il risultato basta inserire una resistenza di piccolo valore, 100 ohm dovrebbero bastare, in serie al condensatore per ridurre la corrente di picco a circa 20 mA sia con l'8u2 che con l'FTDI.
Cerco di verificare strumentalmente la cosa in giornata, sopratutto gli effetti sull'impulso di reset vero e proprio che dovrebbe rimanere ampiamente entro i margini di sicurezza, durata minore di 100 ns, per non resettare l'ATmega.

in pratica la R va tra +5V e il positivo del C? Allora evidentemente si è trattato di un'errata interpretazione dei collegamenti, in precedenza, visto che anche lì c'erano una R da 120 e un C da 10µF in serie rispetto al +5, solo che il negativo del C invece che sul Reset era collegato a massa, mentre sul reset andava il punto di giunzione R-C.
Un dubbio: col "vecchio" sistema era possibile fare ripetuti upload sul chip stand alone ma non era ovviamente possibile aggiornare l'eventuale sketch (magari per fare una prova "locale") su Arduino, è sempre la stessa cosa, o abbiamo qualche miglioria in tal senso?

menniti:
in pratica la R va tra +5V e il positivo del C? Allora evidentemente si è trattato di un'errata interpretazione dei collegamenti, in precedenza, visto che anche lì c'erano una R da 120 e un C da 10µF in serie rispetto al +5, solo che il negativo del C invece che sul Reset era collegato a massa, mentre sul reset andava il punto di giunzione R-C.

Con la r in serie al condensatore tra +5V e il condensatore chiuso verso GND non limiti in nessun modo la corrente che scorre attraverso il condensatore da 100nf, l'energia la prende dal condensatore da 10 uf e non attraverso la resistenza, questa serve solo garantire una ricarica veloce del condensatore, che comunque attraverso la 10k avviene lo stesso in meno di un secondo (partendo dalla scarica completa) quindi assolutamente inutile abbassare questo valore.
In pratica potrebbe bastare la sola resistenza da 120 ohm tra +5V e reset, è in parallelo alla pull up da 10k del reset, ma a differenza del condensatore da 10 uf, che ha una limitata quantità di energia, questa può far scorrere indefinitamente fino a 42 mA, cosa che in caso di errori/distrazioni può creare non pochi problemi.

Un dubbio: col "vecchio" sistema era possibile fare ripetuti upload sul chip stand alone ma non era ovviamente possibile aggiornare l'eventuale sketch (magari per fare una prova "locale") su Arduino, è sempre la stessa cosa, o abbiamo qualche miglioria in tal senso?

Non cambia nulla perché se tieni bloccato l'autoreset di Arduino non puoi caricare un nuovo sketch a meno che non premi fisicamente il tasto di reset.

Grazie, posso approfittare sull'argomento "reset"?
Sto facendo un po' di prove con l'HVFuse, per la programazione del chip mediante l'applicazione di una tensione di 12V al pin reset del chip, per circa un secondo, il tempo di programmare i fusibili. Sto sperimentando dei circuitini che mi permettono di "eliminare" due smd (così faccio un pcb realizzabile senza problemi): un booster che tira fuori 12V a partire dai 5 di Arduino ed un circuito npn-pnp per switchare la tensione di 12V al reset usando un impulso HIGH proveniente da un pin di Arduino. Mi manca un elemento fondamenlate: la corrente richiesta dal pin reset a 12V affinché si possano programmare i fusibili. Questo dato mi serve sia per capire se il booster che sto provando va bene (dovrebbe erogare circa 20mA) che per calcolarmi la R di limitazione dei 12V verso il reset del chip.
Puoi darmi qualche indicazione o al limite qualche schema alternativo? Ripeto l'esigenza è fare un pcb semplice da montare (non per me che sarei attrezzato...) e risparmiare qualche cent.

menniti:
che per calcolarmi la R di limitazione dei 12V verso il reset del chip.

Il data sheet non riporta la corrente massima richiesta dal reset quando gli si collegano i 12 Volt, però se la memoria non mi inganna non servono più di pochi uA, quindi una bella resistenza in serie da 1k giusto per limitare la massima corrente che può fluire su quella linea.
Al limite basta fare una semplice verifica strumentale, metti in serie al reset la r da 1k, fornisci il 12V e controlla con l'oscilloscopio (DSO) come varia la tensione ai capi della resistenza che in questo caso diventa uno shunt per la misura della corrente.

Bene, la prova la faccio per curiosità, ma se sono pochi µA sono a posto, il booster va benissimo, resta lo schema per l'ampli di tensione, da quanto ho capito devo per forza usare un npn che pilota un pnp, altrimenti il solo npn (in uscita dal micro ho un impulso HIGH per il pilotaggio) non conduce nella configurazione a collettore comune. La conferma me la dà proprio la configurazione del chip smd che devo eliminare, fatta in questo modo, anche se speravo di "cavarmela" col solo npn.

Dal punto di vista elettronico viene sfruttato il segnale standard della RS232 DTR (Data Terminal Ready) che normalmente si trova a 1 logico e va a 0 durante la trasmissione dei dati.

Ok, ho seguito tutte le discussioni e voglio fare alcune considerazioni dal lato software:
perchè è necessario resettare arduino board sempre è comunque?
In effetti il DTR messo alto fà parte della prodedura di riconoscimento fatta da avrdude quando comunica con la board. Comunicare con la board significa in sostanza comunicare con il software installato nel micro, software che è il conosciutissimo bootloader.

Avrdude invia dei dati in seriale e si aspetta una determinata risposta, quando questa non è corretta avrdude visualizza il messagio stk500 not in sync (o simile).

Quindi la procedura di reset serve per dialogare con il bootloader, perchè questo entra in azione solo dopo il reset.

Dalla lettura dei post capisco che quando una board arduino viene usata come programmatore ICSP, questo auto reset su questa board non è gradito.
Quindi se ho capito bene, lato software basterebbe mettere nella configurazione dell'ide un flag, es autoreset.disable = true.

Quanto detto mi fa pensare al fatto che il programma ICSP da mettere su arduino non prevede l'uso di un bootloader, cioè non ha necessità di "switchare" tra bootloader e user code, ma dall'altro lato leggo che per la uno board il nuovo bootloader risolve il problema.

La cosa mi interessa lato software per il programma che sto sviluppando (arvdudequi). Al momento sono fermo per vari motivi (uno attendo di fare aquisti, micro ecc).
Alla fine la domanda è:
La cosa è risolvibile lato software evitando di abilitare il DTR, quando si sta usando la board con il programma ICISP?
Ci sarebbe da vedere se questo segnale deve comunque essere cambiato perchè previsto dal protocollo implementato dal programma ICISP, se fosse così non c'è verso di aggire lato software, se non modificando il bootloader come sembra sia stato fatto per l'optiboot, anche se la cosa non mi convince.

Non ho le idee molto chiare in merito, posso chiarirmele leggendo il codice, ma se c'è qualcuno che le ha già più chiare delle mie (idee) lo ascolterei con piacere.

Ciao.

Ciao MT, in poche parole:
usando Arduino come ISP a volte ci si scontra con questo problema dell'autoreset che impedisce di caricare sun un chip stand alone il bootloader o uno sketch qualsiasi. Il problema è legato al singolo hardware, si può verificare indifferentemente su una UNO o 2009 o anche su una compatibile, se si verifica, su quella board si verifica sempre. P.es. la mia UNO funziona senza problemi, la mia 2009 invece richiede la disabilitazione.
L'intervento hardware non è invasivo e serve comunque solo per questi casi.
Se ci fosse un flag software sarebbe certamente comodo, ma dubito che l'IDE lo preveda, invece questo nuovo optiboot "scoperto" da leo sembra risolvere il problema sulle UNO (almeno sulla sua), ma lo lascia sulle 2009, il cui bl è diverso.
Spero di esserti stato utile.

MauroTec:
perchè è necessario resettare arduino board sempre è comunque?

Infatti non è necessario, serve resettare solo per avviare il bootloader o per sbloccare una condizione di crash o loop eterno.

In effetti il DTR messo alto fà parte della prodedura di riconoscimento fatta da avrdude quando comunica con la board.

No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.

Dalla lettura dei post capisco che quando una board arduino viene usata come programmatore ICSP, questo auto reset su questa board non è gradito.

Il problema autoreset ISP a quanto pare si pone solo con la UNO, sulla 2009 non c'è o comunque è raro che si verifichi, dovrebbe essere legato alle diverse temporizzazione usate dall'optiboot e dal bootloader della 2009, non ho indagato a fondo su questa cosa.
In realtà il vero motivo per bloccare l'autoreset è l'uso pratico di Arduino quando serve comunicare tramite la porta seriale USB, ogni volta che la apri Arduino viene resettato perché DTR cambia di stato.

Quindi se ho capito bene, lato software basterebbe mettere nella configurazione dell'ide un flag, es autoreset.disable = true.

Non è così semplice, o meglio sarebbe possibile farlo sulla UNO visto che l'USB è gestita da un micro tramite il quale sarebbe possibile gestire il reset in diverso modo, p.e. tramite uno specifico comando inviato dall'IDE e non tramite un segnale della RS232.

Quanto detto mi fa pensare al fatto che il programma ICSP da mettere su arduino non prevede l'uso di un bootloader, cioè non ha necessità di "switchare" tra bootloader e user code, ma dall'altro lato leggo che per la uno board il nuovo bootloader risolve il problema.

Ribadisco quanto sopra, la questione ISP è secondaria, il vero problema è che l'autoreset resetta Arduino ogni volta che apri la seriale virtuale indipendentemente dal fatto che lo programmi o meno, per verificarlo basta che apri il terminale seriale mentre gira uno sketch e puoi constatare da solo come Arduino resetti ogni volta che lo fai.
Volendo si può bypassare la questione reset ogni volta che si apre la Vcom da un eventuale programma utente che riceve i dati da Arduino, ma non è una cosa semplicissima da mettere in atto e non è detto che il linguaggio di programmazione lo permetta.
Rimane comunque il fatto che spesso e volentieri la verifica/ricezione dati da Arduino viene fatta tramite il terminale dell'IDE o altro programma emulazione terminale che resettano sistematicamente Arduino ogni volta che si apre la comunicaizone.

La cosa è risolvibile lato software evitando di abilitare il DTR, quando si sta usando la board con il programma ICISP?

Si se sai come farlo e se disponi dei giusti strumenti di lavoro software, ma varrebbe solo per un software utente e non per l'IDE.

Ci sarebbe da vedere se questo segnale deve comunque essere cambiato perchè previsto dal protocollo implementato dal programma ICISP, se fosse così non c'è verso di aggire lato software, se non modificando il bootloader come sembra sia stato fatto per l'optiboot, anche se la cosa non mi convince.

Anche il bootloader non sa cosa sia DTR, e non gli serve saperlo, non esiste nessuna modifica al bootloader che può risolvere la questione visto che DTR altro non fa che portare il pin reset a 0 logico, non puoi bloccare l'autoreset dal bootloader.

Ciao Astrobeed, il mio penultimo intervento richiede la tua opinione, l'ultimo invece contrasta (per "esperienza") con un paio di tuoi punti, riguardo il problema con la 2009 (mie prove) e riguardo la questione dell'optiboot (almeno da quanto sostiene leo nel topic che ha aperto un paio di giorni fa).
Mi dai questi chiarimenti?
Grazie

Fatta la prova con il condensatore da 1uf, funziona perfettamente e la risposta del reset è praticamente identica a quella con il condensatore da 10 uf, idem per DTR.
Se metto una resistenza da 100 ohm in serie al condensatore per limitare il picco di corrente su DTR, si arriva al limite sul reset, nel mio caso ho rilevato 0 logico per 1.2 us, e infatti Arduino viene programmato, il che vuol dire che a seconda delle varie tolleranze ci si può trovare sia con l'autoreset bloccato che funzionante.
Tenuto conto che la resistenza in serie al condensatore era solo una precauzione al limite delle "pippe mentali", in realtà non ci sono problemi se non c'è, se proprio si vuole metterla deve essere al massimo da 33 ohm.

menniti:
Mi dai questi chiarimenti?

Partendo dal fatto che dei test su qualche UNO e qualche 2009, che per giunta forniscono risultati completamente opposti, ha valenza statistica 0 penso che a questo punto se non si fa una analisi attenta e dettagliata del fenomeno è impossibile dire la vera causa e quando è realmente necessario bloccare l'autoreset con lo sketch ISP.
La modifica all'optiboot che risolverebbe la questione non l'ho controllata, anzi non ho nemmeno guardato se è disponibile il sorgente, per il semplice motivo che non mi interessa, però al massimo risolve la questione ISP, ma non il vero problema del reset ogni volta che si apre la Vcom come ho puntualizzato qualche post sopra.

L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.

A differenza tua, però, che punti a disabilitare l'autoreset su Vcom, il mio problema era appunto trovare un modo per far funzionare quello sketch senza condensatori. E con l'Optiboot v.4 risolvo.

OT:
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.

Ciao Atrobeed ricordi questo post avrdude -p m328p -c arduino -b 19200 -P /dev/ttyUSB0 -t - #11 by Maurotec - Generale - Arduino Forum

No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.

Allora, vediamo se riusciamo a capirci, concordo con quanto dici, ma obbietto dicendo la seguente:
La seriale tipica dei pc è molto differente dalla comunicazione seriale implementate es sulla 2009, mancano alcuni segnali, cioè ci sono ma non vengono collegati al micro, tranne DTR che viene collegato come hai detto tu.
Il DTR come vedi da codice python è impostabile, è posso assicurarti che se non eseguo la sequenza:

print "Clear DTR and RTS to unload the RESET capacitor"  
ser.setRTS(False)
ser.setDTR(False)
print "attende x tempo"
time.sleep(1)
print "Set DTR and RTS back to high"
ser.setRTS(True)
ser.setDTR(True)

Il bootloader se mi risponde mi dice cose strane insomma non mi dice che è in sync.

Quindi a raggion veduta il DTR è gestibile, lo posso mandare su o giù prima di aprire il device, occhio che qui si può capire male, diciamo che posso aprire il device file impostando il DTR = false, dopo aver aperto il device posso modificare lo stato di tutti i flags, se lo posso fare in python lo si può fare in C++ e in java.
C'è solo una cosa che obbliga ad aprire un device a chiuderlo e riaprirlo ed è il baudrate, in quanto non mi risulta sia possibile modificarlo a caldo.

@Menny
Scusa ho anglofizato il tuo nick, non t'incazà :grin:
Allora avevo capito bene, non si capisce perchè in alcuni casi l'autoreset rompe ed in altri no.

Però non posso indagare sulle reali cause che fanno fallire l'operazione di scrittura, non ricordo se nel connettore
ICISP arrivi il reset, se si probabilmente è qua il problema, se per ipotesi prima di scrivere il micro su breadboard il programma ICISP invia il reset a questo pin e questo è connesso al pin reset di arduino questo si autoresetta.
Io l'ho sparata perchè non posso fare questi esperimenti al momento.

Ciao.

leo72:
L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.

Appena ho un attimo di tempo gli do uno sguardo.

gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.

Questo è un bel mistero, però è ancora più strano che riesci a vederli dal programmatore e riprogrammarli, il danno che illustri non dovrebbe permettere questa cosa.