next topic »

[Reply #360 on:]

Astro Astro Astro

(chiamato a gran voce stile "Il Gladiatore")
 

[Reply #361 on:]

sorry ma sono di fretta
date una lettura a questo documento:
http://www.avrfreaks.net/modules/FreaksFiles/files/382/DN_020.pdf

[Reply #362 on:]

sorry ma sono di fretta
date una lettura a questo documento:
http://www.avrfreaks.net/modules/FreaksFiles/files/382/DN_020.pdf

Arrivi tardi, l'ho già segnalato un paio di volte 
Cmq lì si parla anche di "protezione in scrittura", non solo di lettura però Mike non riesce a proteggere i chip da tale operazione.

[Reply #363 on:]

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  ; dopo i primi 15 giorni di guerra l'elmo gli stava sollevato sulla testa di 30cm

[Reply #364 on:]

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.

[Reply #365 on:]

oh porc... , me la leggo bene anche se mi sono sempre riferito alle tabelle di programmazione e lì parla di due bit e basta.

[Reply #366 on:]

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. ?

[Reply #367 on:]

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 

[Reply #368 on:]

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:

Code:

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

[Reply #369 on:]

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

[Reply #370 on:]

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?

[Reply #371 on:]

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 

[Reply #372 on:]

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.

[Reply #373 on:]

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
http://www.atmel.com/Images/doc0943.pdf

[Reply #374 on:]

perché la combinazione 01 serve appunto per (mi pare) disabilitare la programmazione SPI, non è self-programming....? ma cos'è esattamente?

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.