Topic permanente di programmazione newbie

Testato:
x QT: a me sembra chiarita la questione, infatti con i LB non e' possibile RIPROGRAMMARE, ma solo PRIMA CANCELLARE E POI PROGRAMMARE. In tal senso va letto il datasheet (cosa facile da asserire ora, ma che prima di certo non era chiara, anzi Atmel dovrebbe spiegare meglio la cosa)

Dalla prova che ho fatto NON è necessario prima cancellare, tant'è che ho disabilitato l'auto-erase in AVR Studio ed il log nella finestra di output lo conferma (a meno che AVR Studio non mi pigli per il cuxo), ma puoi riprogrammare a piacere. Nel mio test, con protezione 'light' che permette la lettura, ho RIprogrammato la flash con un binario diverso ed ho successivamente scaricato il contenuto della stessa ottenendo un file .hex assolutamente identico all'originale.
Resta il fatto che con la protezione massima non puoi leggere la flash e questo ti assicura la protezione 'intellettuale' del codice binario. Se vuoi una protezione integrale devi ricorrere al fuse SPIEN.

Ciao
QP

Spettate, allora si stanno sostenendo due cose diverse ?

astrobeed:
Certo che la bloccano, però a condizione che non esegui prima un erase, operazione che viene sempre fatta di defualt da tutti i programmatori, se inibisci tale comando non puoi riscrivere la flash.

QuercusPetraea:
Dalla prova che ho fatto NON è necessario prima cancellare, tant'è che ho disabilitato l'auto-erase in AVR Studio ed il log nella finestra di output lo conferma (a meno che AVR Studio non mi pigli per il cuxo), ma puoi riprogrammare a piacere.

Testato:
Spettate, allora si stanno sostenendo due cose diverse ?

Il test l'ho fatto e con la protezione in scrittura della flash attiva non è possibile caricare un nuovo programma tramite spi se prima non si esegue un erase, dal punto di vista pratico sembra che l'operazione va a buon fine, esattamente come la lettura della memoria protetta, però la flash rimane inalterata.
Oggi rifaccio il test con calma, l'altro giorno li ho fatti in fretta ed è possibile che mi è sfuggito qualcosa.

Per quanto mi riguarda, non ho provato l'opzione -D, perché non mi interessava concettualmente, per i motivi più volte spiegati; il chip_erase resetta i lock bits (è proprio una delle sue funzioni e io l'ho provata) e quindi è ovvio che dopo si possa scrivere; però in un mio precedente intervento ho scritto

ma in condizione FC ho messo il chip con bootloader caricato direttamente su Arduino e sono riuscito ugualmente a caricare un blink, quindi il blocco continua a non avere alcuna utilità.

e questa operazione, se esegue un chip erase lo fa parzialmente perché resta protetta l'area del bl, ma per me chip_erase significa cancellazione totale di flash, eeprom e reset dei lb. Ma se QP dice che disabilitando il chip_erase scrive lo stesso io ci credo. Peraltro sarebbe la prova assoluta di ciò che sostengo da un po' di pagine: la protezione in scrittura è una cag :grin:
Se Astro dedica un po' di tempo magari tira fuori qualcosa di interessante.

Rettifica e smentita di ciò che ho affermato:
Dopo aver lasciato sfiammare i neuroni (settimana di lavoro pesante; come dice Karl Popper "Tutta la vita è risolvere problemi"), ho riprovato con l' "Hello, world" di Arduino cioè Blink, prima con lampeggio ad 1 secondo, poi lampeggio con 5 secondi.
Ebbene...
Il lampeggio resta ad 1 secondo anche se la riprogrammazione sembra andare a buon fine.
In pratica mi sono preso per il cuxo da solo. :blush:

Una volta impostati i lock bit NON si può riprogrammare il micro.

Ciao
QP

QuercusPetraea:
Una volta impostati i lock bit NON si può riprogrammare il micro.

Quindi confermi che, anche se la programmazione "sembra" andata a buon fine, difatti non è così?

QuercusPetraea:
Il lampeggio resta ad 1 secondo anche se la riprogrammazione sembra andare a buon fine.
In pratica mi sono preso per il cuxo da solo. :blush:
Una volta impostati i lock bit NON si può riprogrammare il micro.

Ok, quindi confermi quello che avevo visto pure io, sembra che si riprogramma, ma rimane inalterato.

x Menny.
Se programmi da Bootloader è normale che il micro viene riscritto anche se hai settato i l.b. per la protezione in scrittura perché in questo caso devi settare i relativi l.b. del bootloader che hanno una priorità maggiore rispetto a quelli della flash generica.
Per farla breve, con il blocco in lettura e scrittura della flash generica non puoi scriverla tramite ISP, a meno di non fare un erase, e non puoi scriverla dal software applicativo, non puoi leggerla tramite ISP.
Se non setti nessun l.b. del bootloader questo può tranquillamente leggere e scrivere la flash generica indipendentemente da come settati i relativi l.b. Relativamente al bootloader hai due distinti livelli di blocco, uno che riguarda solo la flash generica (application) che ti permette di inibire singolarmente la lettura e/o la scrittura, l'altro è relativo al bootloader stesso e anche in questo caso puoi inibire singolarmente lettura e/o scrittura per un totale di 8 differenti condizioni come permesso dai relativi quattro l.b.
C'è solo un punto oscuro relativamente ai l.b. della flash generica, due bit consentono quattro diverse combinazioni però ne vengono sfruttate solo tre, apparentemente la condizione che blocca solo la lettura, e non la scrittura, non è permessa toccherebbe verificare se è una carenza del data sheet oppure è un limite reale
In tutti i casi da AvrStudio il menù di settaggio dei l.b. per la flash prevede solo i tre stati indicati sul data sheet il che mi porta a pensare che effettivamente il blocco della sola lettura non sia possibile.

mi autopropongo come coordinatore nazionale dei test :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

grazie QP per il ri-test, Astro tu puoi esimerti dal rifarlo. :slight_smile:

Si. Confermo!

Appena ho un po' di tempo provo con avrdude, che sembra possa vedere AVRDragon, con l-opzione -D che disabilita l'auto-erase e senza bootloader.

Ciao
QP

QuercusPetraea:
Appena ho un po' di tempo provo con avrdude, che sembra possa vedere AVRDragon, con l-opzione -D che disabilita l'auto-erase e senza bootloader.

Probabilmente devi usare dei driver diversi da quelli presenti in AvrStudio esattamente come succede con l'Avrisp MKII, con i driver standard non si può usare da Arduino perché Avrdude non lo vede.

astrobeed:
Probabilmente devi usare dei driver diversi da quelli presenti in AvrStudio esattamente come succede con l'Avrisp MKII, con i driver standard non si può usare da Arduino perché Avrdude non lo vede.

Ho visto. C'è bisogno di installare la libusb-win32 che si trova qui, ma ora non ho tutta questa voglia di provarci. Magari in futuro per approfondire la cosa.

Ciao
QP

astrobeed:
C'è solo un punto oscuro relativamente ai l.b. della flash generica, due bit consentono quattro diverse combinazioni però ne vengono sfruttate solo tre, apparentemente la condizione che blocca solo la lettura, e non la scrittura, non è permessa toccherebbe verificare se è una carenza del data sheet oppure è un limite reale
In tutti i casi da AvrStudio il menù di settaggio dei l.b. per la flash prevede solo i tre stati indicati sul data sheet il che mi porta a pensare che effettivamente il blocco della sola lettura non sia possibile.

Ho provato a programmare i l.b. con FD (4a combinazione) ma alla rilettura dei l.b. il valore si riporta ad FC.
Questa combinazione non è impostabile.

Ciao
QP

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.
Riprendo due frasi di Astro:

Per farla breve, con il blocco in lettura e scrittura della flash generica non puoi scriverla tramite ISP, a meno di non fare un erase, e non puoi scriverla dal software applicativo, non puoi leggerla tramite ISP.

Io con il blocco lb su FC (lettura e scrittura inibite) mediante ISP scrivo tranquillamente, inizialmente provavo con lo stesso sketch, lo dissi chiaramente, poi ho provato due blink assolutamente diversi (sul mio Programmatore ISP dispongo di 3 led): uno su un LED a 1000 e l'altro su un altro LED a 100, mi accorgerò della differenza no? Ogni volta cambia comportamento, quindi scrivo; evidentemente Arduino ISP fa un erase; d'altra parte se AVRDUDE di default fa l'erase è ovvio che ArduinoISP ne erediti i parametri. Ribadisco che tutto ciò è una cag perché questo è come il ferramentaio che ti vende una serratura di sicurezza e contemporaneamente ne da una copia al cugino ladro!

C'è solo un punto oscuro relativamente ai l.b. della flash generica, due bit consentono quattro diverse combinazioni però ne vengono sfruttate solo tre, apparentemente la condizione che blocca solo la lettura, e non la scrittura, non è permessa toccherebbe verificare se è una carenza del data sheet oppure è un limite reale

La combinazione FD NON esiste, non è una carenza ma proprio non è prevista, non solo da data-sheet, ma nemmeno dalla programmazione; vedo che intanto QP ha provato, ma le prove le avevo fatte anche io , senza riportarvele perché erano inutili. Il parametro FD non è accettato e di default viene imposto l'FC. Non penso valga la pena perderci altro tempo, le conclusioni sono e restano quelle a cui ero arrivato, incorniciandole :grin:, un po' di pagine fa. Naturalmente disabilitando il fuse SPI ora sappiamo con certezza che non si programma, ma questo non c'entra nulla con i lb.

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

Si però questa volta stai facendo il sordo :grin:
L'IDE di Arduino se gli dici di programmare un micro tramite ISP non usa l'opzione -D per Avrdude pertanto viene fatto un erase come prima cosa e di conseguenza vengono sbloccati i b.l. il che rende possibile riprogrammare il micro.
Ti ho già spiegato che lo scopo principale dei b.l. relativi alla flash è impedire la lettura della stessa tramite un programmatore hardware, ovvero protezione anticopia, e impedire che sia il tuo programma che un eventuale accesso da ISP/Jtag possono scrivere sulla flash con le conseguenze disastrose che puoi ben immaginare.
Lo scopo dei b.l. non è impedire la riprogrammazione del chip in assoluto, se vuoi questo deve settare gli appositi fuse che disabilitano la programmazione ISP/Jtag, però se lo fai poi se obbligato a passare per l'HV per sbloccare i fuse e non è detto che sia possibile farlo una volta che hai messo il micro sul circuito.
Ti faccio presente che su tutti i micro di questo mondo esiste la protezione anticopia e scrittura, funziona allo stesso modo delgi AVR, ovvero se la setti il solo modo per accedere al micro è eseguire un erase per riportarlo alle condizioni di default.
La cosa è pure logica, cosa te ne fai di un micro che non puoi più programmare ?

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. :grin:
Da AvrStudio puoi settare a piacere tutti i parametri di programmazione, incluso se non eseguire l'erase che è attivo di default.

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

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

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

Testato:

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

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

]:smiley:
@ Tutti: io farò il sordo ma voi fate i grilli :grin: 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? :astonished: 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 :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: Buone cose e grazie di avermi dato del sordo e rincoglionito, è un piacere, se non ci si loda tra amici :smiley: XD

[quote author=Michele Menniti link=topic=95050.msg767884#msg767884 date=1335022332]
Infatti che me frega di AVR Studio e quant'altro se io conduco test con AVRDUDE e IDE? [/quote]

Stavolta mi tocca bacchettarti sul serio :grin:
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 :grin: )
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.

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 :fearful:
    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ì :sweat_smile:
  • 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 :grin: