1284p piantato?

Confermo, le porte sono diverse. Quindi va preso il datasheet del 1284 e ritrovata la corrispondenza tra i segnali.

secondo il tuo articolo michele per la mia mcu dovrei usare connettore test1 , quindi portb, portd xtal1 e pa0, giusto?
Ovviamente tutti correttamente collegati come indicato, e per il firmware vado liscio modificando lo sketch di mightyohm ?
Grazie

Sì. la TEST 1 è per tutta la famiglia PDIP 40 pin W, non ricordo ora se la tua versione ha qualche pin in più quindi ovviamente ti devi rifare ai segnali e non al numero di pin (ma questo lo sai meglio di me :)). Il firmware di mightyohm dovrebbe andare al primo colpo, ma cerca la versione 2.0, sono ragionevolmente sicuro di non aver mai "spostato" un segnale, anche perché tutti i pin del 328P programmatore sono occupati quindi non avrei tratto alcun vantaggio dal farlo, come selezione dovrai scegliere l'atmega328P, per abilitare la programmazione parallela, i segnali sono identici. Invece attenzione ai segnali RST e RESET: il primo è il reset del micro programmatore, il secondo invece è un circuito "interruttore" a transitor, che invia i 12V al reset del tuo 1284 durante le fasi di programmazione, ed è controllato da un pin del micro programmatore. Il circuitino è facilmente replicabile, ti serve una corrente massima di 100mA, ma sono esagerati...., solo che se il tuo micro ha un pur minimo danno (a volte ininfluente sul funzionamento) potrebbe richiedere questa corrente per qualche istante, meglio prevederla.

Niente da fare, ho provato a riprogrammarlo in HV tramite schema e firmware di mightyohm , ma si pianta tutto al momento del 'burning fuses' .
Ci sono troppe variabili in gioco, e il chip potrebbe anche essere danneggiato, anche se non ho la più pallida idea di cosa lo abbia potuto danneggiare!
Ho visto che negli schemi del link la versione 1 utilizzava resistenze da 1k su praticamente tutte le linee, mentre nella versione 2 non ne usa nemmeno 1 :fearful:
IO ho comunque provato sia con che senza.

Ho notato che eseguendo la procedura indicata nel sito, praticamente il chip deve essere messo in un secondo momento.
Ho ipotizzato semplicemente che, per entrare in modalità programmazione parallela, la stessa mcu deve essere avviata praticamente con 12v sul pin di reset, infatti le operazioni preliminari fanno in modo che tale segnale venga portato alto se si specifica una determinata modalità (nel mio caso ATMEGA , scelta 1 ).
Ho dato una guardata in giro ma non ho trovato grandi indicazioni sulla programmazione hv, anche nel datasheet stesso del 1284p non ho trovato cenni.
Sapete indicarmi qualcosa da leggere?

Tiello da parte e quando avrai diversi chip non funzionanti ed un programmatore HV magari gli potrai resuscitare, inutile tribolare per un solo chip
Ciao

niki77:
Ho visto che negli schemi del link la versione 1 utilizzava resistenze da 1k su praticamente tutte le linee, mentre nella versione 2 non ne usa nemmeno 1 :fearful:
IO ho comunque provato sia con che senza.

non servono a nulla.

Ho notato che eseguendo la procedura indicata nel sito, praticamente il chip deve essere messo in un secondo momento.
Ho ipotizzato semplicemente che, per entrare in modalità programmazione parallela, la stessa mcu deve essere avviata praticamente con 12v sul pin di reset, infatti le operazioni preliminari fanno in modo che tale segnale venga portato alto se si specifica una determinata modalità (nel mio caso ATMEGA , scelta 1 ).

questa cosa serve più che altro per il fatto che i due pin seriali del mega328 programmatore sono "implicati" sia nella programmazione che nella comunicazione seriale (menu, ecc.); il chip viene messo dopo solo perché disturberebbe la comunicazione seriale, a mia memoria altro non serve; qualunque comando di lettura/scrittura sul target deve essere accompagnato dall'applicazione dei 12V al pin reset.

Ho dato una guardata in giro ma non ho trovato grandi indicazioni sulla programmazione hv, anche nel datasheet stesso del 1284p non ho trovato cenni.
Sapete indicarmi qualcosa da leggere?

sì, le altre tre puntate del mio articolo sul Programmatore HV :D, ritengo siano fortemente esaustive, "purtroppo" sugli altri articoli non è successo nulla di grave e quindi quelli sono reperibili solo tramite Rivista.

Ops.... mi sà che ho scoperto un fattaccio :smiley:

Se praticamente il 12v deve andare al reset quando si legge e si scrive nel mio circuito sta al contrario.
Sarà perchè ho preso il firmware versione 2 e l'adattatore invece l'ho fatto con un npn come la versione 1. :~
Praticamente per il mio circuito il pin che comanda il reset del target deve essere low per avere 12v su reset e hi per avere 0, ed il firmware fà esattamente il contrario.
Stasera inverto i livelli e riprovo, magari funziona ...

Niki, a volte sei un po' tosto, scusa se te lo dico, ti avevo detto di replicare il mio circuito a due transistor sullo schema della rivista.... quello funziona in "positivo", e peraltro è l'unico modo SERIO di pilotare 12V con un segnale da 5V; la fretta è cattiva consigliera :wink:

Scusa tanto michele ma avevo capito che dall'articolo dovevo astrarre solo la pedinatura.... :sweat_smile:

Del resto non avevo focalizzato che avevi pubblicato anche uno schema elettrico 'funzionante' compatibile con il firmware di mighty ...

Uffa non ci capiamo mai! :roll_eyes:

ti avevo detto di replicare quelle connessioni ed anche garantitto che non avevo apportato variazioni nelle connessioni tra pin e segnali, anche perché sono obbligate da datasheet. In pratica la parte dei socket è perfettamente compatibile con la scheda di mightyohm, che è uno shield di Arduino, io ho realizzato (v. primo dei due schemi sulla rivista) un circuito in stand-alone, per cui il mio firmware opera in modo differente non dovendo gestire un modello di Arduino, ma la parte relativa al dialogo col target deve essere assolutamente identica.
Se ricordi all'inizio ti avevo anche consigliato di cercare la versione 2 di mightyohm, perché è molto simile alla mia, anche se relativa solo a qualche micro; però è certissimo che selezionando atmega attivi la versione compatibile col tuo 1284. Nel mio firmware, molto più potente di quello, c'è tutto un algoritmo (parolone!) che si occupa di analizzare il micro target e restitutire immediatamente le informazioni relative a: modello, valori attuali dei fuse e lock bits, tipologia di programmazione (parallela o seriale); quindi col mio firmware (che però per un anno è di uso esclusivo della Rivista), appena avviato il colloquio vedresti subito se qualcosa non va; infatti se il micro fosse rotto lo sapresti subito, senza bisogno di tentare di scrivere i fuses. Ma comunque nel tuo caso ora ti basta scrivere i fuse. Se però non ricordo male devi attivare il flag che ti chieda anche l'extended, altrimenti ti chiede solo low e high. Volendo puoi impostare la parte iniziale del firmware per attivare la scrittura diretta dei fuses di default (i cui valori fornisci tu nelle variabili iniziali), senza stare a farteli chiedere.

Si c'è da abilitare la scrittura dell efuse, ma quella l'ho già fatta.
Stasera inverto il livello logico del reset e metto fisse le impostazioni della modalità e i valori dei fuse , riattivo la comunicazione seriale solo alla fine per restituirli i valori riletti, così mi rendo conto se ha funziato.
Grazie mille, ti farò sapere come è andata.

di nulla, assolutamente, speriamo bene :sweat_smile:

Fatto!!!

Fusi programmati come dei fusi!!!

uhauhauhauha

:grin:

Ho già rimontato lo scomodo package sulla sua schedona e l'ho già anche riprogrammato via ICSP !!
Anche se facevo prima a ricompare il chip è sempre stata comuque una bella esperienza, grazie a tutti per la preziosa collaborazione!

OTTIMO!!! come giustamente dicevi tu all'inizio non è una questione di soldi e di tempo, ma di problematica ripetibile; ora sai che se dovesse risuccedere, con una mezzoretta sei pronto a risolvere, ovviamente non perderai più tutto questo tempo, i problemi sono tutti risolti.
Ma sai anche che rottura di ....... significhi giocherellare con i fuse al buio. :wink:
Complimenti Niki, al solito sei arrivato a buon fine! :slight_smile:

Resta da capire com'è che l'hai brickato.

Il mio consiglio comunque è quello che ti ho dato anche all'inizio del thread:

leo72:
spero che il parametro "-F" tu lo abbia usato solo in questo caso. Non va mai usato normalmente perché in caso di una comunicazione imperfetta (e può capitare, chi ha programmato centinaia di chip può confermartelo) forzi la scrittura provocando spesso danni.

Resta da capire com'è che l'hai brickato.

vero, verissimo ... però non ne ho veramente la più pallida idea.

L'unico sospetto è che sia mancata la corrente in un momento delicato del processo, infatti l'unica cosa che ricordo è che poco prima che mi accorgessi che il micro non si programmava più , il monitor del pc si è spento e riacceso causa sbalzo di tensione.
Ma se questo non è plausibile allora non ne ho veramente la più pallida idea.

Non uso il parametro -F se proprio non ne sono costretto .
Quando l'ho aggiunto alla riga di comando il chip era già compromesso, mi restituiva già la signature 000000, valeva la pena tentare...

quello della mancanza di corrente è plausibilissimo, ma anche ciò che dicevi all'inizio, la disabilitazione dello SPI. Nel primo caso però è facile perdere la signature, cosa che non è successa a te, altrimento non lo riprogrammavi via ISP, il seocndo caso invece giustificherebbe la mancanza di lettura della signature e la non programmazione nemmeno mediante -F

Sicuramente la signature risultava 000000 non perchè si era cancellata, ma perchè non leggeva più il chip essendosi disattivata la programmazione SPI.
Quindi la mia ipotesi è che si siano sminchiati i fuses durante la programmazione che ha subito lo sbalzo di tensione.
Si sono sminchiati in maniera tale da disattivare la programmazione SPI e tutto il resto ne è la conseguenza.

Plausibile?
Archiviamo? :grin:

niki77:
Quindi la mia ipotesi è che si siano sminchiati i fuses durante la programmazione che ha subito lo sbalzo di tensione.
Si sono sminchiati in maniera tale da disattivare la programmazione SPI e tutto il resto ne è la conseguenza.
Plausibile?

no

Archiviamo? :grin:

:wink: