Riesco a leggere il device Signature, non più i Fuse Bit

Buonasera, sto lavorando a un progetto che prevede un atmega328p-au standalone con clock interno a 8MHz, uso sia avrdudess che l'ide di arduino, con un primo uC ho per sbaglio cambiato gli lfuse e l'ho briccato mettendo 0x00.
Con il secondo sono stato più attento, dunque ho flashato il bootloader dello standalone a 8MHz, e avevo in deepsleep una corrente di 300 uA che era troppa, allora ho letto che disattivando il BOD con gli efuse potevo notevolmente scendere di corrente in sleep mode. Usando avrdudess allora ho modificato SOLO gli efuse ed ora riesco comunque a leggere la signature ma non posso nè leggere i fuse da avrdudess ne riflashare il firmware dall'ide...

inoltre sempre con avrdudess, con un baud di 115200 posso leggere la signature mentre non ho mai potuto leggere i fuse, mentre dopo aver messo il bootloader potevo leggere signature e fuse anche a 19200, ma poi dopo aver cambiato il fatidico efuse, di nuovo, non riesco più a leggere a 19200


qui nello screen si vede che non posso più usare il baud a 19200, prima invece a 19200 potevo fare tutto quanto, non so perchè invece il 115200 funziona sempre ma solo per leggere la signature

Io vedo solo una signatute 0x000000 che NON è una signature valida quindi ... in realtà NON stai leggendo alcun'che ... :roll_eyes:

Guglielmo

se vedi in alto prima della signature 0x000000 c'è un'altra signature (in bianco) usando il baudrate a 115200, quindi teoricamente dovrebbe vederlo seppur in modo strano no?

Ah, ok, non avevo notato le due cose ... quindi a 115200 qualche cosa legge ... ma che programmatore stai usando ?

Guglielmo

sto usando arduino as ISP (con arduino uno) e ho fatto anche una prova con un usbasp, magari pensando che un baudrate di 115200 fosse troppo per l'arduino (dato che è l'unico baudrate che posso utilizzare).
So per certo che non è problema di wiring

Nella tua immagine però io vedo selezionato come programmatore "Arduino" ... sicuro che sia corretto? Hai bloccato l'autoreset del Arduino che usi come ISP?

Guglielmo

nono tranquillo, nella gui di avrdudess lo chiama "arduino", ma di fatto sta dicendo arduino as ISP (l'ho utilizzato gia' un po' di volte).
Se ti riferisci al condensatore che solitamente va messo sul programmatore non l'ho messo poiche' volevo evitare di fare danno confondendomi, siccome quando funzionava non l'ho utilizzato, ho preferito non metterlo nemmeno ora cosi' da evitare di attribuire il problema al cablaggio

Il condensatorino da 10µF tra il +5V e Reset è probabilmente d'obbligo ... non c'è una regola fissa, dipende dal Arduino che usi come ISP. Una delle migliore guide sulla programmazione con Arduino as ISP è quella del Prof. Menniti e riporta chiaramente (dopo decine e decine di prove fatte):

Nei vari Topic visitati ho potuto constatare che tale problema si verifica o non si verifica indifferentemente, su qualsiasi Arduino, per cui Vi assicuro che non è “legge” il fatto che su 2009 non si debba disabilitare l’autoreset e su UNO sì, o viceversa. Semplicemente, se l’operazione non va a buon fine bisogna disabilitare l’autoreset, a prescindere dall’hardware che si sta usando; questo mi hanno insegnato le decine e decine di prove che ho dovuto fare per poter produrre questo lavoro. Chiarisco che se Arduino necessita di questo intervento per poter portare a buon fine l’operazione, non c’è speranza che se ne possa fare a meno, quindi la prossima volta bisognerà montare direttamente il condensatore, senza fare inutili tentativi.

Infilare il condensatorino nei due buchi non costa nulla ... prova ... :roll_eyes:

Guglielmo

Ho cercato di fare un po' di prove per dare un quadro generale piu' chiaro possibile.
Il capacitore non ha dato nessun effetto benefico, al contrario, non e' possibile leggere nemmeno la signature.
Ho provato con diversi baudrate e combinazioni.
Intanto mi sono accorto con i verbose che nell'ide di arduino, usando arduino as ISP in realta' la avrdude.conf richiama il programmatore stk500v1 mentre utilizzando il tool avrdudess si utilizza "genuinamente" arduino as ISP.
infatti se provo a leggere la signature utilizzando il baudrate a 115200 con il .conf dell'ide ottengo errore di signature non corretta, se utilizzo lo stesso baudrate con il .conf di avrdudess ottengo la signature dell'atmega328p.

inoltre un'altra cosa curiosa e' che nello sketch di arduino as ISP e' possibile cambiare il baudrate che l'arduino utilizza nelle vesti di programmatore, se provo a modificare il baudrate dello sketch succede che:

Se lo compilo con 19200 nello sketch e provo a leggere la signature da avrdudess (dato che e' l'unico modo che funziona), imponendo il baudrate di 19200 legge la signature ma la legge sbagliata quindi 0x000000 mentre a 115200 legge sempre la signature giusta

Se lo compilo con 115200 nello sketch e provo a leggere la signature sempre da avrdudess, imponendo il baudrate di 19200 questa volta si blocca direttamente, a 115200 legge sempre la signature giusta.

Spero di essere stato chiaro

Non so che dirti ... onesstamente ho sempre ritenuto "Arduino as ISP" un accrocchio e ho sempre evitato di usarlo, utilizzando solo veri programmatori (AVRISP MKII, AVR Dragon e Atmel ICE) e ... non ho mai avuto il benché minimo problema ... :roll_eyes:

Comunque, leggendo qua e la, chi lo usa, nessuno mi sembra abbia i tuoi problemi ...
... io, invece che fare prove alla rinfusa, ti consiglio di seguire alla lettera la vecchia guida (sempre valida) del prof. Menniti che trovi QUI ... poi fai come credi, io di più non so.

Guglielmo

purtroppo lo so e' un problema alquanto bizzarro, ma sai la cosa ancora piu' strana e' che ci sono stati dei chip vergini che ho ordinato che non ho capito come ma riuscivo a leggere la signature ma non i fuse bit, poi ho caricato il bootloader con arduino, e con lo stesso baudrate poi sono riuscito a leggere anche i fuse, non capisco che cosa avviene ogni volta...sono cose particolari, e soprattutto non tutti gli utenti vanno a smanettare in maniera troppo profonda, pero' mi piacerebbe molto capire ogni singola cosa del micro, queste soprattutto.
Ad ogni modo visto che ci sono ne approfitto e ti chiedo, ho visto su aliexpress dei cloni HVPP che funzionano con atmel studio, Programmatore ad alta tensione AVR, dedicato alla serie Mega8, supporta Mega168, 328, programmazione parallela AVR|Light Beads| - AliExpress
secondo te e' un buon acquisto? con questo potrei resettare i fuse e rianimare il micro.

ma poi mi chiedo io, e' possibile che il solo cambio degli efuse per il BOD porti a tutti sti problemi? teoricamente non dovrebbe influire in nessun modo...

Guarda, se cerchi un ottimo programmatore HV ad un prezzo abbordabile, io ti consiglio QUESTO che, in passato, ho avuto modo di usare più volte, altri ... non mi seprimo se prima non li ho provati.

Il solo cambio del BOD NON può provocare problemi ... evidentemente deve essere stato modificato qualche altro bit... ti ricordi sempre vero che i fuse si programmano mettendoli a ZERO (e non ad UNO come si è abituati a fare per altri registri) ...

Guglielmo

(grazie per la shield, l'avevo vista gia' un po' prima ma sicuramente con il fatto che me la consigli quasi quasi un pensierino glielo faccio).
Si questa cosa quando l'ho saputa mi ha profondamente turbato ma ho letto anche tutte le motivazioni legate all'architettura del micro che appunto giustificano l'inversione dei bit, comunque stavo leggendo la guida che mi hai inviato (di cui sconoscevo l'esistenza), e ovviamente dice che i fuse bit si cambiano nel momento in cui si va a masterizzare un bootloader, ma allora mi chiedo, puo' essere che per un qualche assurdo motivo con il fatto che io ho solo spartanamente cambiato i fuse senza fare una procedura di bootloading mi abbia generato questo problema? magari perche' il bootloader si aspetta di lavorare con dei fuse bit mentre io successivamente ne ho caricati altri senza "dirlo" al bootloader?
Sono domande che mi faccio giusto per trovarmi delle risposte e mettermi il cuore in pace...

No, modifico spesso i FUSE con il codice già caricato e non c'è alcun problema ... se si toccano solo i FUSE non viene modificato altro. Ovvio, non bisogna scrivere codice (che va a sovrascrivere il bootloader) e non bisogna cambiare i FUSE che lo riguardano direttamente.

Guglielmo

Quindi in poche parole non ha senso quello che mi e' successo, perche' il BOD non se lo fila di striscio il bootloader.
Comunque grazie mille per le dritte, vedro' a questo punto di utilizzare un HVPP per farlo resuscitare, speriamo bene...
Teoricamente un HVPP e' sempre in grado di rianimare un avr briccato? in qualunque configurazione errata di fuse bits?

Teoricamente si ... praticamente, a me ha sempre funzionato, però .. la mano sul fuoco non ce la metto :stuck_out_tongue_winking_eye:

Guglielmo

ahahah, va bene allora sono gia' piu' tranquillo che anche se sbaglio posso ritornare indietro, grazie mille di tutto, e' stato molto interessante. :slight_smile:

Sicuro non sia un chip a basso costo, un fondo di magazzino ? Se li prendi dai "cinesi" occhio che qualcuno ti da il bidone.

si lo so... ho avuto esperienza con gli attiny85 rivelatisi poi degli attinyqualcos'altro con 1kb di flash, ad ogni modo questi sono dei 328p originali perche' li ho recuperati da vecchi pcb che mi sono fatto assemblare ai tempi da un noto sito, e determinati siti non credo possano rifilarti bidoni...