Astro interviene d'ufficio di solito, evidentemente non ha seguito questa parte di discussione oppure nemmeno lui ha mai sperimentato fisicamente i lock bits.
Purtroppo le ho provate tutte, il comportamento a monte è perfetto:
da stato FF (free) posso passare a FE (write protect) o direttamente a FC (write e verify protect), da FE posso passare a FC, tutte le altre direzioni non sono consentite; posso solo resettare a FF con un chip erase oppure inviando uno sketch che, sulla carta, non dovrebbe accettare.
Nelle condizioni FE o FC non riesco più a programmare i fuse, nemmeno con l'HV, e questa per me è la prova che i lock bits, almeno qui, stanno facendo il loro dovere; infatti sul reference è scritto chiaramente che i fuse non sono programmabili se i LB non sono settati su FF.
Poi, tutto felice, vado a mandare una blink qualsiasi e passa che è una bellezza, allora a che cavolo serve tutto sto casino?
MI sembra tanto la storia del signore medievale che andava in guerra dopo aver messo la cintura di castità alla bella moglie e poi le lasciava la chiave appesa al collo :P; dopo i primi 15 giorni di guerra l'elmo gli stava sollevato sulla testa di 30cm 
Uhm... forse ho capito. Leggendo il datasheet, pagg. 283 e seguenti, mi par di capire che ci siano due coppie di lock bit, una coppia protegge la memoria del bootloader e l'altra coppia protegge la memoria flash dell'applicazione. Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.
oh porc... :0, me la leggo bene anche se mi sono sempre riferito alle tabelle di programmazione e lì parla di due bit e basta.
leo72:
Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.
Non mi dite che non vi siete mai accorti che ci sono due distinti blocchi di L.B. ?
astrobeed:
leo72:
Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.Non mi dite che non vi siete mai accorti che ci sono due distinti blocchi di L.B. ?
Chi??? Noi????? Ceeeeeerrrrrtoooooooo 
Allora, cerchiamo di capirci: a me del blocco dei BLB non frega assolutamente nulla, avendolo intepretato come riguardante l'area riservata al bootloader; io ho sempre parlato di LOCK BITS, che sono due e riguardano la memoria flash e l'eeprom:
LB Mode LB2 LB1
1 1 1 No memory lock features enabled.
2 1 0 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.(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.(1)
“1” means unprogrammed, “0” means programmed
la nota conferma che il byte 0b11111100 rappresenta la massima protezione.
Ora se mi dite che invece di questi devo programmare il BLB va bene, ma Vi chiedo gentilmente di darmi indicazioni chiare, io faccio grande fatica con i data-sheet in inglese, e a me dappertutto è sembrato che la protezione della flash si facesse con i LB e NON con i BLB 
Mike, a rileggere il datasheet io la intendo come la intendi tu. I lock bit BLBxx dovrebbero servire ad impedire la scrittura della flash da parte del bootloader quindi in teoria programmando via SPI si salta il bootloader quindi devono valere i lock bit LB e basta. Però a te non funziona, in questo modo, quindi io una prova impostando anche i lock bit BLB la farei, tanto tentare per tentare ormai...
leo72:
Mike, a rileggere il datasheet io la intendo come la intendi tu. I lock bit BLBxx dovrebbero servire ad impedire la scrittura della flash da parte del bootloader quindi in teoria programmando via SPI si salta il bootloader quindi devono valere i lock bit LB e basta. Però a te non funziona, in questo modo, quindi io una prova impostando anche i lock bit BLB la farei, tanto tentare per tentare ormai...
Lo so Leo, però non è proprio uno schiocco di dita, ogni nuova implementazione mi costa una giornata; l'unica cosa a cui penso è che mi pare che avevo letto che la 4a combinazione dei Lock bits, cioè la 01 (sul reference credo sia prensente in un punto solo, ma poi non la riportano nelle programmazioni. A proposito: ma tu volevi dire via ISP o proprio via SPI? No, perché la combinazione 01 serve appunto per (mi pare) disabilitare la programmazione SPI, non è self-programming....? ma cos'è esattamente?
L'SPI sta per Serial Peripheral Interface ed è la programmazione tramite i segnali MOSI/MISO/SCK che vengono spediti sui relativi pin. E' la programmazione "standard" degli Atmega ed Attiny.
Cmq ora vado a dormire, domattina sveglia alle 5:20, ne riparliamo dopo queste 5 orette di sonno 
leo72:
L'SPI sta per Serial Peripheral Interface ed è la programmazione tramite i segnali MOSI/MISO/SCK che vengono spediti sui relativi pin. E' la programmazione "standard" degli Atmega ed Attiny.
Cmq ora vado a dormire, domattina sveglia alle 5:20, ne riparliamo dopo queste 5 orette di sonno
buonanotte, mi sa che allora ho trovato l'inghippo, se setto questo valore credo di disattivare l'ISP, vedremo.
Ti riferisci ai lock bit BLB?
Cmq ho trovato anche questo doc, guarda se ti può "ispirare": c'è la sequenza dei comandi per impostare i lock bit da spedire al micro
Se disabiliti la programmazione SPI poi non riesce più a programmare il micro, devi per forza ripristinarla e si può fare solo tramite JTAG, per i micro che la supportano e se non è stata disabilitata pure questa, oppure con l'erase totale, il che include i fuse, tramite HV.
Dei lock bit per il bootloader puoi fregartene altamente, tanto vengono settati come serve quando vai a programmare l'eventuale bootloader via ISP.
OK, e comunque mi sbagliavo, le combinazioni sono proprio tre e non c'è nulla che riguarda l'SPI; del fatto che poi servisse l'HV ovviamente non mi potevo preoccupare, sto realizzando un HV e c'ho pure messo la funzione Chip_Erase :D; i comanid sono inseriti correttamente, come detto se la sequenza non fosse esatta alla rilettura non vedrei i nuovi valori dei LB, che infatti mi impediscono la programmazione dei Fuse finché non faccio un Chip_Erase.
Il blocco della programmazione dei fuse è l'unico effetto tangibile dei LB. Sul fatto di ignorare i BLB c'ero, visto che parlava espressamente di boot, infatti non mi sono proprio guardato la procedura.
Ripeto la richiesta: avreste un programmino semplice semplice (che non sia AVR Studio perché sono a corto di tempo...) che possa accedere alla flash di un qualsiasi chip ATmega (tra quelli che usiamo solitamente), leggendone in qualche modo il contenuto, anche parziale? Mi interessa solo per vedere se in condizione FC almeno ho bloccato l'accesso in lettura, altrimenti davvero non so che cosa l'ho implementata a fare la funzione
Usa Avrdude per fare un dump della flash.
astrobeed:
[quote author=Michele Menniti link=topic=95050.msg764161#msg764161 date=1334731144]
Ripeto la richiesta: avreste un programmino semplice semplice (che non sia AVR Studio perché sono a corto di tempo...) che possa accedere alla flash di un qualsiasi chip ATmega (tra quelli che usiamo solitamente), leggendone in qualche modo il contenuto, anche parziale? Mi interessa solo per vedere se in condizione FC almeno ho bloccato l'accesso in lettura, altrimenti davvero non so che cosa l'ho implementata a fare la funzione
Usa Avrdude per fare un dump della flash.
[/quote]
Ottimo! ma io con AVRDUDE finora ho fatto solo operazioni con i fuse e caricamenti di .hex nel micro; avresti una sintassi "tipo" da suggerirmi, così stasera la provo e vediamo finalmente che succede 
avrdude -p m328p -c stk500 -P COMxx -U flash:r:"flash.hex":i
Dove COMxx indica la porta seriale utilizzata e il percorso per il file; eventaulmente dopo -P COMxx puoi stabilire un baudrate differente dal predefinito inserendo -b .
Inoltre, sostituendo il parametro flash con eeprom puoi leggere la eeprom.
Ciao
QP
Riprendendo ciò che ha prodotto la tua IDE direi di provare questo:
avrdude -CC:\arduino-0022\hardware/tools/avr/etc/avrdude.conf -patmega328p -cstk500v1 -P\.\COM60 -b19200 -Uflash:r:C:\Flash.hex:i
zwzz:
Mostly networked community.
Spammer, segnalato ai moderatori.
astrobeed:
zwzz:
Mostly networked community.Spammer, segnalato ai moderatori.
Idem.
OK, grazie ad entrambi, stasera al rientro faccio subito un tentativo e vi riporto i risultati