Go Down

Topic: Topic permanente di programmazione newbie (Read 38348 times) previous topic - next topic

astrobeed


Però leggendo bene l'intervento di QP NON capisco se ha usato o meno il -D con AVRDUDE;


Meno male che sia io che Q.P. abbiamo scritto chiaramente che i test sono stati fatti tramite AvrStudio e programmatore hardware vero, Avrisp MKII nel mio caso, Avr Dragon per Q.P.  :smiley-mr-green:
Da AvrStudio puoi settare a piacere tutti i parametri di programmazione, incluso se non eseguire l'erase che è attivo di default.

QuercusPetraea


Come detto non ho provato il -D perché non mi interessava. Però leggendo bene l'intervento di QP NON capisco se ha usato o meno il -D con AVRDUDE; perché se non lo ha usato e quindi ha lasciato il chip erase attivo, e non è riuscito a scrivere, la cosa sarebbe in totale conflitto con le mie prove; se invece l'ha usato siamo nella norma; io senza il -D ho scritto regolarmente.
Come detto non mi interessa la questione bootloader perché mi riferisco agli stand-alone, ho solo detto di aver fatto le relative prove.

EDIT: ho riscritto la prima parte di questo post, da rileggere, please.


Per le prove rifatte questa mattina a neuroni freschi non ho utilizzato AVRDUDE ma AVR Studio e confermo che impostando i l.b. ad FE o FC NON sono più in grado di riprogrammare la flash.
Mike, il paramtero -D di AVRDUDE significa "Disable auto erase for flash" ovvero disabilita l'auto erase per la flash. Se non lo metti AVRDUDE esegue una cancellazione della flash prima di spedire il programma. Per cui -D ti deve interessare se vuoi verificare la funzionalità de l.b.
Come contro prova, riprogramma la flash senza -D come hai fatto e poi verifica l'effettivo stato dei l.b. Se sono cambiati ad FF o sono ancora ad FC-FE.

Ciao
QP

Testato


Si però questa volta stai facendo il sordo  :smiley-mr-green

Stavo pensando la stessa cosa, tutte questi test lo hanno fatto precocemente invecchiare.
:)
Prof riprenditi, lascia perdere per un paio di giorni, poi sara' tutto piu' chiaro  :)
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Michele Menniti



Si però questa volta stai facendo il sordo  :smiley-mr-green

Stavo pensando la stessa cosa, tutte questi test lo hanno fatto precocemente invecchiare.
:)
Prof riprenditi, lascia perdere per un paio di giorni, poi sara' tutto piu' chiaro  :)

]:D
@ Tutti: io farò il sordo ma voi fate i grilli :smiley-mr-green: Dove sta scritto che nel seguire uno (io) che fa delle prove ed aiutarlo ad arrivare a delle conclusioni, ognuno (voi) faccia quello che vuole? :smiley-eek: Infatti che me frega di AVR Studio e quant'altro se io conduco test con AVRDUDE e IDE? Quello che mi state ribadendo ogni volta l'ho capito dalla prima, anche se non ci credete, ma ormai stiamo scadendo nel "Quo vadis?". Quindi è inutle che sto a ripetere che ho capito ed a ribadire che questo non cambia la mia idea sulla protezione lb: io NON ho detto che NON funziona (questo alla fine dei fatti....) ma solo che fa cag il modo in cui funziona, né ho mai detto di voler ottenere un chip inprogrammabile ma solo di volerlo rendere non immediatamente sprogrammabile dal primo che passa e collega Arduino ad una USB. Queste incomprensioni nascono dal fatto che ognuno di noi segue perfettamente il proprio filo ma alla lunga perde quello degli altri, poi si ci mette Testato che non ha alcun filo da seguire e tenta di rompere quelli degli altri e la frittata è servita :smiley-yell: :smiley-yell: :smiley-yell: Buone cose e grazie di avermi dato del sordo e rincoglionito, è un piacere, se non ci si loda tra amici :D XD
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

astrobeed


Infatti che me frega di AVR Studio e quant'altro se io conduco test con AVRDUDE e IDE?


Stavolta mi tocca bacchettarti sul serio  :smiley-mr-green:
Poco importa se usi l'IDE di Arduino e Avrdude, o avrdude da riga di programma, o Avrstudio e un programmatore hardware, i risultati sono sempre gli stessi a parità di condizioni di test, ovvero poco importa che strumenti usi, a patto siano quelli giusti, se le condizioni del test sono uguali per tutti.
Ti ripeto per l'ennesima, e spero ultima, volta che non esiste nessun micro che puoi proteggere dalla riscrittura tramite un programmatore a meno che non vengano settati appositi flag (fuse) interni, in certi casi poi non è più possibile tornare indietro, il micro rimane cristallizzato per sempre, oppure è possibile annullare il settaggio tramite particolari procedure.
Con gli AVR il solo modo per proteggerli totalmente dalla riprogrammazione è disabilitarla tramite fuse, sono stati inseriti apposta, operazione non reversibile tramite sistemi normali, e non credo che ti piace dover smontare un micro dal pcb per doverlo mettere sullo zoccolo di un programmatore HV per resettare i fuse (santa Microchip che non ha questi problemi visto che l'equivalente della HV lo puoi fare onboard  :smiley-mr-green: )
Quello che non riesci a capire è che il programmatore hardware, e non avrdude che è solo un programma di interfaccia tra il pc e il programmatore, è uno strumento che ha la massima priorità, gli è sempre permesso di cancellare la memoria del micro e riscriverla salvo speciali "paletti" che per la loro rimozione richiedono l'uso di strumenti speciali.

Michele Menniti

Quo vadis? sarei tentato di fare un collage dei miei interventi, ma vedo che non servirebbe a niente. Ci rinuncio e, naturalmente, mi tengo le bacchettate. Poi è più forte di me.... :~
Prendiamo queste affermazioni:
- i lb si resettano con la programmazione ISP o mediante AVRDUDE (senza -D)
- l'unico modo di proteggere il micro in scrittura è disabilitare il fuse SPI
- con i lb su FC la lettura è effettivamente disabilitata e non c'è modo di superare questo blocco se non con un chip_erase
- nessun essere umano, dotato di intelletto minimo, vuole bloccare un micro per sempre
Se non siete d'accordo con queste affermazioni allora io sono un deficiente (ma rispiegate per favore). Se invece siete d'accordo trovate un solo mio intervento in cui affermo il contrario :smiley-eek-blue:
Il punto è che io faccio delle affermazioni che vanno oltre il funzionamento del sistema, che ritengo di aver capito bene, ma voi continuate a rispiegarmi le cose che io continuo a dire di aver capito, come se non le avessi capite. Cioè secondo voi, visto il funzionamento di lb, fuse, ISP, AVRDUDE, Programmatori AVR vari, io NON posso affermare, parlando di mcu in stand-alone:
- E' stupida la gestione dei LB, riguardo la protezione in scrittura del micro (perché il datasheet dice ...), perché non serve a nulla, visto che qualsiasi tentativo di riprogrammazione va a buon fine, senza dover fare niente, visto che il chip_erase è ATTIVO di default. Non ho detto che non ho capito perché questo avviene, ma solo che è stupido che avvenga così :smiley-sweat:
- NON c'è modo, per le stesse ragioni di cui sopra, di settare un micro per proteggerlo da scrittura ma NON da lettura; lasciamo stare se ha significato o meno fare questa cosa (spiegavo la possibilità di evitare l'incidente di cancellazione, senza che il firmware debba essere protetto da copia). L'opzione FE che è dichiarata espressamente per proteggere la scrittura ma NON la lettura, NON Funziona, in quanto posso scrivere (non è importante il "perché" io possa scrivere ma il fatto che "possa scrivere" senza sforzo alcuno). E se disabilito lo SPI non posso nemmeno leggere, oltre che scrivere.
Allora la domanda della settimana è:
posso farle queste due ultime affermazioni pur confermando come veritiere le prime quattro? Se continuate a sostenere il contrario trovatemi Voi una combinazione di lb e fuses che mi permetta di leggere la flash e di non poterla scrivere, SENZA ricorrere a opzioni (-D p.es.), ma usando gli strumenti standard a disposizione di ogni utente di Arduino (ArduinoISP e AVRDUDE).
Uff, per me vi arrendete :smiley-mr-green:
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

QuercusPetraea


Prendiamo queste affermazioni:
- i lb si resettano con la programmazione ISP o mediante AVRDUDE (senza -D)
- l'unico modo di proteggere il micro in scrittura è disabilitare il fuse SPI
- con i lb su FC la lettura è effettivamente disabilitata e non c'è modo di superare questo blocco se non con un chip_erase
- nessun essere umano, dotato di intelletto minimo, vuole bloccare un micro per sempre
Se non siete d'accordo con queste affermazioni allora io sono un deficiente (ma rispiegate per favore).


Queste affermazioni sono ineccepibili e mi trovi daccordo.

Quote

- E' stupida la gestione dei LB, riguardo la protezione in scrittura del micro (perché il datasheet dice ...), perché non serve a nulla, visto che qualsiasi tentativo di riprogrammazione va a buon fine, senza dover fare niente, visto che il chip_erase è ATTIVO di default. Non ho detto che non ho capito perché questo avviene, ma solo che è stupido che avvenga così :smiley-sweat:


Si. Utilizzando solo i l.b. la gestione della protezione in scrittura è stupida se posso fare un chip erase

Quote

- NON c'è modo, per le stesse ragioni di cui sopra, di settare un micro per proteggerlo da scrittura ma NON da lettura; lasciamo stare se ha significato o meno fare questa cosa (spiegavo la possibilità di evitare l'incidente di cancellazione, senza che il firmware debba essere protetto da copia). L'opzione FE che è dichiarata espressamente per proteggere la scrittura ma NON la lettura, NON Funziona, in quanto posso scrivere (non è importante il "perché" io possa scrivere ma il fatto che "possa scrivere" senza sforzo alcuno).


Per quanto riguarda la scrittura ri-confermo che la gestione è stupida. Con un chip erase puoi riscrivere.

Quote

E se disabilito lo SPI non posso nemmeno leggere, oltre che scrivere.


Questo completa in buona misura la protezione ma a quel punto non hanno più molto senso i l.b.

Quote

Allora la domanda della settimana è:
posso farle queste due ultime affermazioni pur confermando come veritiere le prime quattro? Se continuate a sostenere il contrario trovatemi Voi una combinazione di lb e fuses che mi permetta di leggere la flash e di non poterla scrivere, SENZA ricorrere a opzioni (-D p.es.), ma usando gli strumenti standard a disposizione di ogni utente di Arduino (ArduinoISP e AVRDUDE).


Si. Ho capito quello che vuoi dire. Non esiste una combinazione di l.b. e fuse che permetta la lettura della flash ma non la riprogrammazione visto che posso fare un chip erase.

Quote

Uff, per me vi arrendete :smiley-mr-green:


E' solo questione di capirsi.

Ciao
QP

astrobeed


fare questa cosa (spiegavo la possibilità di evitare l'incidente di cancellazione, senza che il firmware debba essere protetto da copia). L'opzione FE che è dichiarata espressamente per proteggere la scrittura ma NON la lettura, NON Funziona, in quanto posso scrivere (non è importante il "perché" io possa scrivere ma il fatto che "possa scrivere" senza sforzo alcuno). E se disabilito lo SPI non posso nemmeno leggere, oltre che scrivere.


Quello che ti ostini a non voler capire è che la protezione da scrittura serve unicamente per impedire al software utente di scrivere sulla flash, è una cosa che può succedere, in particolari condizioni, anche se non desiderata, non serve per proteggerti da eventuali cancellazioni da programmatore hardware.

Michele Menniti


E' solo questione di capirsi.

E' esattamente ciò che intendevo, ovviamente detto in modo scherzoso XD

@ Astro: scusami, tu sai quanta stima ho di te e quanto io mi fidi ciecamente di ciò che dici, ma stavolta non riesco a convincermi, e non ti chiedo nemmeno di insistere; però c'ho lavorato troppo su questa cosa; sarà, come dice Test, che devo smaltire, però tu hai riportato queste indicazioni del datasheet:
Quote
The user can select:
• To protect the entire Flash from a software update by the MCU.
• To protect only the Boot Loader Flash section from a software update by the MCU.
• To protect only the Application Flash section from a software update by the MCU.
• Allow software update in the entire Flash.

io me le sono andate a cercare e le trovo sotto la voce
Quote
Boot Loader Lock Bits
, che non sono quelli che mi interessano. Invece sotto la voce
Quote
Lock Bit Protection Modes
trovo:
Quote

Memory Lock Bits    Protection Type
LB Mode LB2 LB1
     1       1    1       No memory lock features enabled.
     2       1    0       Further programming of the Flash and EPROM is disabled in
                            Parallel and Serial Programming mode. The Fuse bits are
                            locked in both Serial and Parallel Programming mode.(1)
     3       0    0       Further programming and verification of the Flash and EEPROM
                            is disabled in Parallel and Serial Programming mode. The Boot
                            Lock bits and Fuse bits are locked in both Serial and Parallel
                            Programming mode.

Il mio inglese è pessimo e lo sappiamo tutti, ma mi pare che anche QP e Leo trovino stravaganti queste definizioni; qui non si riferisce affatto alla scrittura da parte del software, qui parla chiaramente di modo di programmazione parallelo e seriale che, per quanto ne so, dovrebbe essere la SPI e non c'entra niente con l'"autoscrittura" della flash da parte del firmware che avviene internamente alla mcu.
Poi ce la diciamo tutta e quindi mentre tu sai benissimo di cosa stiamo parlando, io invece sono un ignorante, per cui tu ti basi sulle tue stratosferiche conoscenze ed io solo sulle poche righe tradotte sudando sangue e verificate con centinaia di prove. Però se tu non tiri fuori la tua scienza per dimostrare che queste righe dicono ciò che tu dici e non ciò che io leggo, non puoi pretendere di convincermi "a capire", perché ti direi che hai ragione solo per chiudere la questione, ma io resterei insoddisfatto nel dover convincermi di una cosa che non mi convince affatto. Oppure diciamo tutti che ATMEL ha scritto due stronzate a proposito dei Lock Bits e questo mi basta; almeno tutto il mio errore si baserebbe sull'errore di una fonte che dovrebbe essere ineccepibile. Come detto, non sei tenuto ad insistere, se ti sei fatto l'idea che so' de coccio no problem, però per un solo attimo dimentica la tua scienza e mettiti dal mio punto di vista :~
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72

#474
Apr 22, 2012, 12:31 am Last Edit: Apr 22, 2012, 12:36 am by leo72 Reason: 1
Devo spezzare una lancia a favore di Mike.
Se sul datasheet c'è scritto che attivando i Lock Bits si può disattivare la scrittura seriale (quindi SPI) e/o la lettura e ciò non avviene, le cose son 2: o il datasheet è sbagliato oppure non è spiegato bene in che condizioni ciò si verifica.

Io non sono un esperto, però credo di capirlo l'inglese, e quella frase mi pare che dica questo. Se poi servono i bit LBL allora vuol dire che quella tabellina in cui sono riportate le combinazioni dei lock bit LBx non serve a un czz

EDIT:
parlo senza aver fatto test (non ho al momento possibilità di farli) ma penso che ci siano diverse decine di test fatti

EDIT2:
c'è poi il fuse SPIEN, però se davvero serve attivare questo fuse bit per disattivare la scrittura, perché nella tabella dei lock bit non ce lo scrivono? "Devi attivare LBx e SPIEN sennò non ottieni nessun risultato".
Allora alla fine il mio sistema è quello più sicuro: disattivi il pin di reset e togli il bootloader. E tanti saluti. Se poi ci metti anche uno SPIEN disattivato sei a posto.

Michele Menniti

#475
Apr 22, 2012, 12:38 am Last Edit: Apr 22, 2012, 12:57 am by Michele Menniti Reason: 1

Devo spezzare una lancia a favore di Mike.
Se sul datasheet c'è scritto che attivando i Lock Bits si può disattivare la scrittura seriale (quindi SPI) e/o la lettura e ciò non avviene, le cose son 2: o il datasheet è sbagliato oppure non è spiegato bene in che condizioni ciò si verifica.

Io non sono un esperto, però credo di capirlo l'inglese, e quella frase mi pare che dica questo. Se poi servono i bit LBL allora vuol dire che quella tabellina in cui sono riportate le combinazioni dei lock bit LBx non serve a un czz

Ma nemmeno, secondo me; i BLB (non LBL  :)) fanno quello che dicono (almeno sulla carta :smiley-sweat:) e cioè proteggono separatamente l'area boot e l'area application, ma SOLO se utilizzi il bootloader e NON possono risolvere il problema dei LB per questa semplice ragione:
Quote
Program the Fuse bits and Boot Lock bits before programming the LB1 and LB2.
quindi come è possibile che i BLB possano gestire il funzionamento dei LB se questi ultimi bloccano la programmazione dei BLB? Sarebbe un controsenso ridicolo. D'altra parte mi pare che si sia d'accordo tutti sul fatto che i BLB e i LB agiscano separatamente ed i primi solo in caso sia presente il bootloader nel micro.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Michele Menniti


EDIT:
parlo senza aver fatto test (non ho al momento possibilità di farli) ma penso che ci siano diverse decine di test fatti

Le prove le ho fatte io, non meno di un centinaio :smiley-eek-blue:
Quote

EDIT2:
c'è poi il fuse SPIEN, però se davvero serve attivare questo fuse bit per disattivare la scrittura, perché nella tabella dei lock bit non ce lo scrivono? "Devi attivare LBx e SPIEN sennò non ottieni nessun risultato".
Allora alla fine il mio sistema è quello più sicuro: disattivi il pin di reset e togli il bootloader. E tanti saluti. Se poi ci metti anche uno SPIEN disattivato sei a posto.

E' la domanda che mi sto e sto ponendo da giorni; c'è qualcosa che non torna. Comunque, come detto, disattivare il reset o lo SPIEN è la stessa identica cosa, se NON c'è il bootloader, entrambi impediscono sia la lettura che la scrittura della flash.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Testato

Mike io sono d'accordo con la tua analisi. Sommando ad essa il reale comportamento del micro, che sottolineo  ormai e' chiaro come funziona perche sia i tuoi test che quelli di  astro che quelli di qp portano gli stessi risultati, il dato di fatto e' un grave errore del datasheet nella spiegazione del funzionamento dei LB.
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

astrobeed

x Tutti

Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV.
Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro.

Possibile che non vi entra in testa questa cosa tanto semplice ?
Possibile che non capite che se bloccate nel vero senso della parola la cancellazione del micro tramite programmatore poi lo potete buttare via se dovete aggiornarlo ? Una volta esistevano i micro OTP (One Time Programming) che si programmavano solo una volta, sono spariti non appena la flash è scesa a costi accettabili perché era veramente assurdo dover sostituire il micro per fare un update del software.




QuercusPetraea


x Tutti

Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV.
Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro.


Tutta questa apparente confusione deriva dal significato che diamo ai termini "alterare" e "riprogrammare" la flash.
Dalla nota applicativa AVR910, pagina 8 penultimo paragrafo, si afferma: "Per proteggere il contenuto della memoria da una sovrascrittura accidentale o da letture non autorizzate , i lock bit possono essere impostati per proteggere i contenuti della memoria ecc. ecc."
Io associo questa affermazione al termine alterare. Posso sovrascrivere parte o tutta la flash dopo aver impostato i l.b.?
No.

Più avanti la nota applicativa precisa: "Il solo metodo per riguadagnare l'accesso alla memoria dopo aver impostato i lock bits è di cancellare l'intero chip con un comando 'chip erase'. I lock bits saranno impostati ad 1, disabilitando la protezione, solo in seguito ad una pulitura di tutte le locazioni di memoria".
In questo caso il termine appropriato può essere riprogrammare. Dopo aver pulito tutta la flash, con la conseguente disabilitazione dei lock bits, posso riprogrammare la flash?
Si.

Poi si può discutere se la cosa è furba o stupida. Ma questo è un altro livello del discorso, in cui non si parla più dei lineamenti dei lock bits (cosa fanno) ma della loro efficacia (come lo fanno).

Ciao
QP


Go Up