Topic permanente di programmazione newbie

Non ti preoccupare, quelli sono i parametri che avrdude ha nel file avrdude.conf relativamente al chip che sta gestendo, quindi è un sunto di tutto, anche di ciò che non usa in quel particolare momento.
La riga che ci interessa è questa:

avrdude -CC:\arduino-0022\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\.\COM60 -b19200 -Uflash:w:C:\DOCUME~1\DOTT~1.MIC\IMPOST~1\Temp\build1887152033353859677.tmp

I parametri sono:
-v -v -v -v: specifica una modalità "super verbose", ossia che manda a video qualsiasi messaggio generato
-patmega328p: specifica atmega328p
-cstk500v1: specifica il tipo di programmatore (stk500v1 è l'emulazione che offre l'ArduinoISP)
-P\.\COM60: porta usata
-b19200: velocità
-Uflash:w:C:.....: fimware usato e memoria programmata, ossia la flash

Quindi, non c'è nessun dettaglio relativamente alla cancellazione del chip, che sarebbe il parametro -e, che opera un erase totale della flash, della eeprom e dei fuse del micro. Il parametro "-e" dovrebbe essere usato dall'IDE solo quando programma il bootloader.

Boh, l'unico dato certo è che con le opzioni FE o FC non riesco più a programmare i fuse, segno che i lb stanno funzionando, niente da fare invece sulla questione programmazione, gli sketch passano che è una bellezza.
Sarebbe interessante il parere di qualcuno che li ha usati, ma ho idea che non c'è nessuno.
Comunque stanotte ho terminato i due firmware (PC e LCD) con la gestione lettura/scrittura dei Lock bits, la procedura funziona, non posso entrare nel merito del funzionamento dei lb, anche se mi piacerebbe capirlo.

Avevo chiesto se avete un qualcosa di semplice con cui possa "leggere" il contenuto della flash del micro, naturalmente non mi interessa alcuna estrapolazione o traduzione di codice, solo capire se almeno la lettura viene impedita.

Ora mi dedico ad altre cosette, tra qualche giorno (devo smaltire :disappointed_relieved:) riprendo tutto e scrivo il terzo ed ultimo articolo sull'HV.

Non so che dirti, non ho ancora avuto mai il modo di doverli usare.
So solo che anche l'IDE di Arduino li programma (basta aprire il file boards.txt per vedere la voce dei lockbit).
Mi viene da pensare che un "programmatore" software qual è l'ArduinoISP non riesca a compiere l'operazione, e che forse ci vorrebbe un programmatore "vero".

Astro Astro Astro

(chiamato a gran voce stile "Il Gladiatore")
:slight_smile: :slight_smile: :slight_smile:

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

BrainBooster:
sorry ma sono di fretta :slight_smile:
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 :wink:
Cmq lì si parla anche di "protezione in scrittura", non solo di lettura però Mike non riesce a proteggere i chip da tale operazione.

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 :stuck_out_tongue_closed_eyes:

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 :sweat_smile:

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 :disappointed_relieved:

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 :cold_sweat:

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 :cold_sweat:

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.