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
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?
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?
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 ...
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.
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 ...
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.
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) ...
(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.
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?
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...
