Topic permanente di programmazione newbie

Scusa Mike ma ogni tanto perdo il filo del tuo ragionamento e delle tue necessità.... Scrivi: [quote author=Michele Menniti link=topic=95050.msg765378#msg765378 date=1334824242] NON riesco a leggere con AVRDUDE (bene!) RIESCO a scrivere con AVRDUDE (male!). [/quote]

Poi affermi invece: [quote author=Michele Menniti link=topic=95050.msg765540#msg765540 date=1334831811] il micro non è sovrascrivibile via ISP(bene!) ma non è più neanche leggibile (male!) [/quote]

Quindi ora non ti va bene che sia leggibili ma ti va bene che non sia riscrivibile però ieri dicevi l'esatto opposto :sweat_smile:

Scusa se rispondo io.
E’ proprio quello che fa il bootloader. Scrive nella zona definita Application section che è la flash decurtata della quantita riservata all’area del bootloader. Per farlo, il codeice del bootloader fa uso di macro in assembly che utilizzano l’istruzione (assembly) SPM.
Un esempio tratto da boot.h, alla 7a riga

#define __boot_page_fill_short(address, data)   \
(__extension__({                                 \
    __asm__ __volatile__                         \
    (                                            \
        "movw  r0, %3\n\t"                       \
        "out %0, %1\n\t"                         \
        "spm\n\t"                                \
        "clr  r1\n\t"                            \
        :                                        \
        : "i" (_SFR_IO_ADDR(__SPM_REG)),        \
          "r" ((uint8_t)__BOOT_PAGE_FILL),       \
          "z" ((uint16_t)address),               \
          "r" ((uint16_t)data)                   \
        : "r0"                                   \
    );                                           \
}))

Ciao
QP

Se è per questo, è possibile per lo stesso codice scrivere all'interno di sé stesso, ossia un programma può cambiare in tempo reale il contenuto della memoria che occupa. A parte le considerazioni sul fatto che se si sbaglia locazione di memoria poi si rende il codice ineseguibile, la possibilità c'è ed è documentata dal datasheet.

@Menniti , quindi obbiettivo raggiunto :) ....anche se http://www.cl.cam.ac.uk/~sps32/mcu_lock.html ;)

@ QP: grazie del chiarimento, 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à. Forse, come dicevi tu stesso mi pare, bisognerebbe mettere mano anche ai BLB, però l'uovo non vale la candela.

@ Leo: vuoi farmi passare per un rincoglionito :grin:? La premessa fondamentale è che io NON voglio proteggere alcun firmware, ma devo solo presentare un progetto del Programmatore HV spiegandone caratteristiche ed uso, quindi immagino che uno che lo voglia realizzare voglia poi provare a sfruttarne tutte le caratteristiche. La prima coppia di affermazioni era legata al settaggio FC che, teoricamente, doveva impedirmi sia di leggere che di scrivere, non è così, una bene, una male. La seconda coppia riguarda il fatto che in condizione FE (solo write protect), con l'ausilio della SPI disabled mi aspettavo di non poter più scrivere ma di poter continuare a leggere, così non è, uno bene, uno male. I miei giudizi riguardano le prove che faccio rispetto a ciò che mi aspetto come esito, non sono assoluti, perché sto usando uno strumento che deve poter agire parzialmente su questi parametri; non sto cercando, come premesso di proteggere un micro. Chiaro ora? :) la mia mente è salva per ora :D?

@ BB: come battuta va benissimo, ma restando in tema l'obiettivo è raggiunto; scusa, se sto progettando uno strumento che ha la funzione chip erase non ho certo bisogno di ricorrere ad un tesista russo per farmi cancellare un micro (ciò che ho "intuito" dando un'occhiata al volo al tuo link).

[quote author=Michele Menniti link=topic=95050.msg765599#msg765599 date=1334835540] @ Leo: vuoi farmi passare per un rincoglionito :grin:? La premessa fondamentale è che io NON voglio proteggere alcun firmware, ma devo solo presentare un progetto del Programmatore HV spiegandone caratteristiche ed uso, quindi immagino che uno che lo voglia realizzare voglia poi provare a sfruttarne tutte le caratteristiche. La prima coppia di affermazioni era legata al settaggio FC che, teoricamente, doveva impedirmi sia di leggere che di scrivere, non è così, una bene, una male. La seconda coppia riguarda il fatto che in condizione FE (solo write protect), con l'ausilio della SPI disabled mi aspettavo di non poter più scrivere ma di poter continuare a leggere, così non è, uno bene, uno male. I miei giudizi riguardano le prove che faccio rispetto a ciò che mi aspetto come esito, non sono assoluti, perché sto usando uno strumento che deve poter agire parzialmente su questi parametri; non sto cercando, come premesso di proteggere un micro. Chiaro ora? :) la mia mente è salva per ora :D? [/quote] No, il rinco... sono io perché siccome non mi ricordo le cose, poi mi tocca andare a ricercare ciò che uno scrive per seguire il filo del discorso, solo che poi mi intreccio lo stesso XD Ti chiedo, tu vuoi impedire la scrittura E la lettura, giusto?

no, il mio intento esatto è: impedire la lettura e/o la scrittura, ecco perché NON ho raggiunto il 100% del mio scopo: oggi posso impedire la lettura, posso impedire la lettura e la scrittura, ma NON posso impedire la scrittura lasciando libera la lettura. Questa è da incorniciare :grin:

Mike, ma questo non potrai mai ottenerlo. I lock bit servono proprio per impedire primariamente la lettura della memoria: sono nati come una sorta di "lucchetto" (da "lock") per bloccare ogni tentativo di copia del firmware non autorizzata. Lo scopo primario è proprio quello di evitare che un cinese si svegli la mattina e decida di clonare un certo dispositivo basato su un micro. Anche se non è in possesso del codice del firmware, che gliene frega? Compra uno di quei dispositivi, fa un dump del firmware, dopo di che realizza 100000 copie del dispositivo ed in ogni micro inserisce il firmware che ha prelevato dal micro. A lui non importa che sia in codice macchina, tanto lo deve semplicemente rimettere in un altro micro.

Se usciamo da questo presupposto, usciamo dal significato di lock bit.

leo72: Mike, ma questo non potrai mai ottenerlo. I lock bit servono proprio per impedire primariamente la lettura della memoria: sono nati come una sorta di "lucchetto" (da "lock") per bloccare ogni tentativo di copia del firmware non autorizzata. Lo scopo primario è proprio quello di evitare che un cinese si svegli la mattina e decida di clonare un certo dispositivo basato su un micro. Anche se non è in possesso del codice del firmware, che gliene frega? Compra uno di quei dispositivi, fa un dump del firmware, dopo di che realizza 100000 copie del dispositivo ed in ogni micro inserisce il firmware che ha prelevato dal micro. A lui non importa che sia in codice macchina, tanto lo deve semplicemente rimettere in un altro micro. Se usciamo da questo presupposto, usciamo dal significato di lock bit.

Forse vuoi dire una cosa diversa da ciò che intendo io, rileggiti il mio post in cui ho copiato le caratteristiche dei due lb, in breve: FE: write protect FC: write & verify protect quindi in FE teoricamente dovrei poter leggere (e lo faccio) ma non scrivere (ma lo faccio lo stesso); poi mettiamola sul filosofico ed hai ragione tu, ma il datasheet parla chiaro. ;)

Ma astro ti ha spiegato che l'impedimento alla scrittura non si applica ai tentativi "interni", fatti cioè dal bootloader. Ecco perché ti dicevo che secondo me dovresti togliere il bootloader e disattivare il pin di reset.

[quote author=Michele Menniti link=topic=95050.msg765673#msg765673 date=1334838407] Forse vuoi dire una cosa diversa da ciò che intendo io, rileggiti il mio post in cui ho copiato le caratteristiche dei due lb, in breve: [/quote]

Michele stai travisando completamente il significato, e l'uso, dei L.B., adesso non ho tempo per darti una spiegazione dettagliata, devo uscire e vado di fretta, più tardi ti spiego per bene il tutto.

intervengo giusto per spezzare una lancia Michele in genere non travisa niente, a limite sono i manuali che sono scritti criptici ed interpretabili :)

Io anche mi sarei aspettato che usando protezione massima non avrei potuto programmare il micro

attendiamo illuminanti delucidazioni al fine di buttarci in test atti a conferme/smentite (in genere con voi e' la prima opzione che si avvera :))

Ho fatto un paio di prove veloci settando tutte le varie possibilità dei lock bit tramite Avrstudio e l'Avrisp MKII, più che altro per essere certo di quello che stavo facendo senza dover combattere con lo sketch AvrIsp e avrdude. Tramite i due lock bit per la flash è possibile bloccare solo la scrittura da parte di un applicativo della stessa e la lettura tramite un qualunque sistema esterno, però rimane completamente accessibile ad un programma che si trova nell'area del bootloader se dichiarato come tale tramite gli appositi fuse. In pratica anche attivando i lock bit della flash il bootloader può sempre leggere e scrivere la porzione dove si trova il programma, è possibile impedire al bootloader di leggere la flash bloccando la modalità LPM nella zona applicazione, il che permette di continuare a riprogrammare il micro ma non di leggerne il contenuto, il che crea problemi nella fase di verify, se si blocca anche la SPM diventa impossibile programmare il micro tramite bootloader. La stessa cosa è applicabile alla sola zona del bootloader, ovvero è possibile impedire che tale area venga letta o scritta oppure tutti e due. Per farla breve, i due lock bit per la flash agiscono solo su questa esclusa l'eventuale zona del bootloader, i quattro lock bit relativi al bootloader permettono di bloccare lettura e scrittura da parte di questo sia del resto della flash che della zona del bootoader stesso, se non c'è il bootloader ovviamente non serve settare i relativi bit. Se si cerca di caricare un nuovo sketch tramite l'IDE con la modalità SPM in area applicazione del bootloader bloccata con i relativi l.b. questo è l'errore che ritorna avrdude:

avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x62
avrdude: verification error; content mismatch

se ho capito bene tu dici che a massima protezione e' possibile programmare la flash via bootloader ma non via ICSP. Mentre il Menny sta dicendo che anche via ICSP riesce a caricare il blink :)

Testato: se ho capito bene tu dici che a massima protezione e' possibile programmare la flash via bootloader ma non via ICSP.

Via ICSP lo programmi sempre per il banale motivo che prima devi comunque cancellarlo, quindi vengono rimosse tutte le eventuali protezioni, per proteggerlo contro questa eventualità va disattivato l'apposito fuse che blocca la programmazione (SPIEN).

astrobeed: ...Per farla breve, i due lock bit per la flash agiscono solo su questa esclusa l'eventuale zona del bootloader, i quattro lock bit relativi al bootloader permettono di bloccare lettura e scrittura da parte di questo sia del resto della flash che della zona del bootoader stesso, se non c'è il bootloader ovviamente non serve settare i relativi bit.

Che è poi quello che ho cercato di spiegare sommariamente nel reply #417, ma una prova è meglio 1000 parole.

Ciao QP

QuercusPetraea: Che è poi quello che ho cercato di spiegare sommariamente nel reply #417, ma una prova è meglio 1000 parole.

Si, infatti avevi spiegato correttamente la cosa. Ho voluto fare un test pratico relativo ai l.b. del bootloader perché non ho mai avuto bisogno di settarli visto che normalmente utilizzo gli AVR programmandoli direttamente via ISP o Jtag quindi se devo proteggerli contro la copia mi basta settare i due l.b. della flash normale.

La questione dei bit LBL l'avevo già fatta presente anch'io un paio di giorni fa. Però Mike ha delle esigenze particolari perché come avete letto: [quote author=Michele Menniti link=topic=95050.msg765654#msg765654 date=1334837910] il mio intento esatto è: impedire la lettura e/o la scrittura, ecco perché NON ho raggiunto il 100% del mio scopo: oggi posso impedire la lettura, posso impedire la lettura e la scrittura, ma NON posso impedire la scrittura lasciando libera la lettura. Questa è da incorniciare :grin: [/quote]

leo72: La questione dei bit LBL l'avevo già fatta presente anch'io un paio di giorni fa. Però Mike ha delle esigenze particolari perché come avete letto:

Per quanto riguarda la flash generica è solo possibile inibire la scrittura, da parte del software, e contemporaneamente la lettura, solo la lettura no, per quanto riguarda il bootloader è possibile impedire la lettura e la scrittura singolarmente, o tutte e due, sia per la sola flash generica che per la sola area del bootloader, ovvero sono possibili tutte le combinazioni. Una curiosità, nel momento in cui si setta LB2, blocco programmazione della flash, diventa impossibile modificare i lock bit del bootloader pertanto sono da settare prima di attivare LB2 altrimenti tocca fare un erase (non serve che sia HV) del micro per poterli scrivere.

QuercusPetraea: Nella descrizione della funzionalità dei LBx indica le tre possibili impostazioni:

1) No memory lock features enabled.

2) Further programming of the Flash and EEPROM is disabled in Parallel and Serial Programming mode. The Fuse bits are locked in both Serial and Parallel Programming mode.

3) 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.




Da questa descrizione io capisco che si riferisce alla programmazione parallela e seriale (intesa come ISP/SPI), ma (suppongo) possa ancora funzionare tramite bootloader che utilizza l'istruzione SPM (Store Program Memory) per caricare i programmi sulla Application Section della flash.
Se così fosse, bisogna agire sui fuse BLBxx per inibire, secondo le modalità indicate sul datasheet, la scrittura sulla flash memory.
Ciao
QP

Boh, a me pare tanto la storia del "Quo Vadis?" che vi raccontai tempo fa. Io non dubito che tu abbia spiegato bene la cosa, anzi sai bene quanto io mi fidi della tua opinione, però riprendo le tue parole "una prova vale più di mille parole". Anch'io ho sempre inteso ESATTAMENTE che sia la funzione 2 che la 3 mi bloccassero la programmazione ISP (quindi come dice Test, che ringrazio, io non traviso assolutamente nulla), ma NON è così e lo sto dimostrando con i fatti; SOLO la disabilitazione del fuse SPI mi impedisce di scrivere nella flash! Astro ti dà ragione ma poi sostiene il contrario dicendo che l'ISP si può fare sempre e si può bloccare solo tramite FUSE. Leo dice che bisogna bloccare il RESET. Io ho detto chiaramente che voglio insegnare a proteggere un micro stand-alone, quindi devo ignorare la programmazione dei boot LB. Nell'intervento di Astro che leggo in diretta lui sostiene che non si può bloccare la sola lettura, invece io dico di sì, e l'ho scritto 10 volte, ma il mio sì non è teorico (la modalità 3 parla chiaramente di lettura e scrittura bloccati) bensì pratico (in modalità 3 non riesco a leggere ma riesco a scrivere). Ho la sensazione che ci stiamo incasinando, quindi l'unica è la domanda chiusa: Se voglio mettere tizio in condizioni di poter leggere la memoria flash, ma di non poterla sovrascrivere, cosa devo fare? Io non ci sono riuscito. :)