MODALITA' GOD MODE
per Win 7 - GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Programmazione:
Vi è morto un AtTiny-xx?
Proviamo a riesumarlo!
Utilizzeremo un AtTiny85, qualche riga di codice e un pochino di hardware
per tentare di rimettere in servizio un AtTiny che sembra essere morto stecchito.
Di questi aggeggini autocostruiti ne esistono parecchie versioni
sul Web e tutti sembrano fare il miracoletto descritto sopra,
...ma non è così...
Per gli smanettoni come me questo progettino fa veramente i miracoli,
permette di rimettere in vita una serie di microcontrollori dati per bruciati.
Chip supportati dal programma:
AtTiny13, AtTiny24, AtTiny25, AtTiny44
AtTiny45, AtTiny84, AtTiny85
Questi chip vengono utilizzati un pò dappertutto, un esempio
pratico è sui moduli DIGISPARK dove il piccolo AtTiny85
ogni tanto va in crash quando gli si tira un pò troppo il collo
o gli si programmano i FUSES in modo errato.
Capita che durante la programmazione di questi dispositivi
qualcosa non vada a buon fine, emerge quindi il classico errore
da parte dell'IDE del programmatore che ci informa che il dispositivo
non esiste, non risponde o addirittura ne rileva un'altro modello.
Tutto dipende dai famosi FUSES interni al chip, che per qualsiasi
imprevisto durante la programmazione vengono scritti in modo errato.
Conosciamo tutti il sistema HVSV Programming che provvede a
programmare vari chip tramite una tensione aggiunta di +12V,
ma anche utilizzando questo sistema professionale non si
riesce più a 'colloquiare' col chip e quindi lo si crede 'morto'
Quando succede questo e si è provato in tutti i modi a riprogrammare
il chip, ma 'lui' non risponde, ci si sente impotenti e l'unico gesto da
fare è quello di centrare il cestino portarifiuti col 'chip morto'.
TAAAC ...AMEN!
Però, dovo svariati canestri messi a segno (...e non) ho ripensato
a lungo sul difetto che spesso mi rovinava le giornate, quindi
mi sono messo alla ricerca di ulteriori informazioni sul caso.
Mr. Google è stato come sempre fantastico, in breve tempo
ho trovato in rete altri sfortunati che come me lamentavano lo
stesso problema, e in mezzo a così tante informazioni ho trovato
il sito di un
GENIO che con ostinazione pura è riuscito
a capire il perchè del problema e lo ha risolto 'quasi' al 99%.
Quell' 1 % rimasto comprende i chip 'arrostiti'... e ci sta!
Ho quindi adattato il software del GENIO e mi sono costruito
un circuito stampato per 'riesumare' questi preziosi chips.
Questo è lo schematico:
Ecco come si presenta, l'ho disegnato con DipTrace:
Ho inserito una femmina USB-B come ingresso per l'alimentazione a 5V,
un survoltore che da 5 eleva a 12 Volt per la tensione di programmazione HV,
uno zoccolo da 8 pin, un bus ISP espandibile per zoccoli SMD e un pulsante.
Qui sotto un preview di come come si presenta la scheda con il modulo
di espansione SMD a innesto e i files Gerber del progetto:
Nulla vi vieta comunque di assemblarlo su basetta millefori
oppure direttamente sulla vostra affezionatissima breadboard,
molto velocemente e con quattro componenti in croce.
Perchè succede che non va più?
In breve, sembra che quando il buon Murphy ci mette lo zampino
faccia in modo che una errata scrittura dei valori dei FUSES
scaturisca in una configurazione del clock casuale dai 32 a 128 KHz.
Uno pensa, vabbè, ma tanto se il micro è 'buono' deve poter
comunicare col programmatore a qualunque velocità, no?
Quindi basterebbe riprogrammare i FUSES a dovere, o no?
Verissimo, ma il vero problema sta nel firmware dei programmatori!
Nel senso che, quando un programmatore 'chiama' il chip e
poi si mette in attesa di una risposta (HANDSHACKING)
per capire chi c'è connesso sul bus di programmazione,
pare che abbia molta fretta di farlo... tanta fretta.
FRETTA? ma che stiamo dicendo?
Eh si, la temporizzazione di attesa del programmatore
pare sia troppo breve, e questo vale per una lunga
lista di programmatori che vengono normalmente utilizzati,
dai più semplici fino ai modelli professionali.
Un altro problema riguarda la protezione dei FUSES
da parte di un registro dedicato, la Memory Lock Bits.
Ecco un sunto tratto dal datasheet:
Se erronamente vengono alterati questi valori può
succedere che il chip non possa più essere programmato
ma FORTUNATAMENTE il comando CHIP ERASE può
risolvere l'inghippo e riabilitare il chip al 100%.
Infatti, sempre dal datasheet possiamo leggere questa nota:
Siamo a cavallo, finalmente una bella notizia!
Qualche info in più...
In sostanza ecco cosa succede durante la programmazione
sopprattutto nella fase iniziale, l'HANDSHACKING:
1:
il programmatore alimenta il chip poi cambia di livello
un pin del bus (SDO) che è connesso a un pin del chip e...
SI METTE IN ATTESA DI UNA RISPOSTA.
2:
il chip si attiva, 'sente' il cambio di livello sul pin (SDO) e dopo un
istante mantiene il livello (SDO) basso per almeno 4 millisecondi
3:
il programmatore quindi 'sente' su (SDO) la risposta del chip
e passa alle prossime fasi, quali programmazione, lettura,
verifica del codice e, a richiesta, la protezione di alcune
parti o di tutta la memoria del chip (Flash e EEprom)
E qui scatta l'inganno, il programmatore aspetta per un
tempo BREVISSIMO che NON E' sufficiente a sentire
la risposta del chip dato per morto, si perchè il poveretto
ora lavora in modalità clock in KHz, peggio di un bradipo!
Poverino, è troppo lento nella risposta, ma continuiamo...
4:
dopo un pò il programmatore 'si rompe le balle'
di aspettare il bradi-chip e decide di interrompere
ogni attività in sospeso, informa l'operatore del problema
...ed ecco che scatta al volo il classico 'vaffanc..o!'.
... è tutto qui! Chiaro no?
...ve l'avevo detto che il sw andava di fretta!
NOTA:
Nella realtà, dopo l'errore di temporizzazione il programmatore
scrive lo stesso i dati da inviare al chip, ma quest'ultimo non
essendo 'pronto a ricevere' perde il sincronismo di clock.
Ne consegue una programmazione sporca che fa strage
dei poveri bit nella memoria del chip.... a caso!
Alla successiva verifica dei dati ecco scaturire l'errore.
Guarda i segnali e le temporizzazioni durante la programmazione,
è un esempio di come si comportano i segnali sul bus ISP:
Dispositivo bloccato:
SDO va basso ma poi il chip non risponde
Dispositivo sano:
SDO va basso e il chip risponde correttamente
a blocchi di dati ordinati temporalmente.
Notare come si comporta la linea (SDO) quando la comunicazione
è OK rispetto al micro con i FUSES settati erroneamente.
E' lampante che la linea del clock presenta un unico e lungo
burst assolutamente non sincronizzato con la linea (SDO).
Soluzione del 'Genio'
Alla fine poi era semplice, bastava aspettare qualche millisecondo in più...
La mè nona la disèva: "La pazienza è la virtù dei forti..."
Qualche nota sul principio di funzionamento dello sketch:
Il software inizialmente analizza il chip e cerca di leggere la
sua 'Signature Bytes' in modo da identificarlo correttamente
per poi assegnargli i tre valori di default dei FUSES
in base al modello di processore rilevato.
Rilevata la 'Signature Bytes' provvede a cancellare tutta
la memoria FLASH del chip con il comando 'CHIP ERASE'.
Ricalcola e riscrive i FUSES corretti in base al modello.
Dopo un ulteriore controllo e rilettura dei FUSES, se l'operazione
è andata a buon fine il software lo segnala tramite un LED
facendo tre lampeggi veloci e una pausa lunga.
Se invece non riesce a identificare il chip oppure
non riesce a scrivere i FUSES farà lampeggiare il LED
con velocità diverse a seconda dell'errore rilevato.
Se invece non fa nessun lampeggio il chip è bruciato o
non è stato inserito correttamente nello zoccolo.
Lo sketch da caricare su un AtTiny85 provvede a interrogare
i dispositivi ad esso collegati mantenendo le giuste temporizzazioni.
Ho modificato alcuni punti chiave e ho commentato il software.
Ricordatevi di settare l'IDE di Arduino come da istruzioni allegate
e di riscrivere il bootloader prima della programmazione
in modo da impostare tutti i parametri correttamente.
Bene, vi metto a disposizione il pacchetto per farvi il circuitino
in questione, nel file c'è tutto l'occorrente.
Ringrazio mr. Uri Shacked per il grande lavoro svolto
e la preziosissima documentazione condivisa in rete.
...CHAPEAU...
Your sniffed IP is:
- All rights reserved - 2022/2023 - Tutti i diritti riservati.
I marchi citati sono di proprieta' delle rispettive aziende - All trademarks are the property of their respective owners and companies.
Carlo Manzoni - Via Enrico Fermi, 10 - 26848 San Fiorano (Lo) - Mobile: +39 338 3114954 - C.F: MNZCRL57A04H844O
(i numeri sconosciuti sono bloccati, al cellulare rispondo solo previo SMS/Whatsapp di presentazione)