Go Down

Topic: Topic permanente di programmazione newbie (Read 33 times) previous topic - next topic

Michele Menniti

#475
Apr 22, 2012, 12:38 am Last Edit: Apr 22, 2012, 12:57 am by Michele Menniti Reason: 1

Devo spezzare una lancia a favore di Mike.
Se sul datasheet c'è scritto che attivando i Lock Bits si può disattivare la scrittura seriale (quindi SPI) e/o la lettura e ciò non avviene, le cose son 2: o il datasheet è sbagliato oppure non è spiegato bene in che condizioni ciò si verifica.

Io non sono un esperto, però credo di capirlo l'inglese, e quella frase mi pare che dica questo. Se poi servono i bit LBL allora vuol dire che quella tabellina in cui sono riportate le combinazioni dei lock bit LBx non serve a un czz

Ma nemmeno, secondo me; i BLB (non LBL  :)) fanno quello che dicono (almeno sulla carta :smiley-sweat:) e cioè proteggono separatamente l'area boot e l'area application, ma SOLO se utilizzi il bootloader e NON possono risolvere il problema dei LB per questa semplice ragione:
Quote
Program the Fuse bits and Boot Lock bits before programming the LB1 and LB2.
quindi come è possibile che i BLB possano gestire il funzionamento dei LB se questi ultimi bloccano la programmazione dei BLB? Sarebbe un controsenso ridicolo. D'altra parte mi pare che si sia d'accordo tutti sul fatto che i BLB e i LB agiscano separatamente ed i primi solo in caso sia presente il bootloader nel micro.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Michele Menniti


EDIT:
parlo senza aver fatto test (non ho al momento possibilità di farli) ma penso che ci siano diverse decine di test fatti

Le prove le ho fatte io, non meno di un centinaio :smiley-eek-blue:
Quote

EDIT2:
c'è poi il fuse SPIEN, però se davvero serve attivare questo fuse bit per disattivare la scrittura, perché nella tabella dei lock bit non ce lo scrivono? "Devi attivare LBx e SPIEN sennò non ottieni nessun risultato".
Allora alla fine il mio sistema è quello più sicuro: disattivi il pin di reset e togli il bootloader. E tanti saluti. Se poi ci metti anche uno SPIEN disattivato sei a posto.

E' la domanda che mi sto e sto ponendo da giorni; c'è qualcosa che non torna. Comunque, come detto, disattivare il reset o lo SPIEN è la stessa identica cosa, se NON c'è il bootloader, entrambi impediscono sia la lettura che la scrittura della flash.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Testato

Mike io sono d'accordo con la tua analisi. Sommando ad essa il reale comportamento del micro, che sottolineo  ormai e' chiaro come funziona perche sia i tuoi test che quelli di  astro che quelli di qp portano gli stessi risultati, il dato di fatto e' un grave errore del datasheet nella spiegazione del funzionamento dei LB.
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

astrobeed

x Tutti

Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV.
Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro.

Possibile che non vi entra in testa questa cosa tanto semplice ?
Possibile che non capite che se bloccate nel vero senso della parola la cancellazione del micro tramite programmatore poi lo potete buttare via se dovete aggiornarlo ? Una volta esistevano i micro OTP (One Time Programming) che si programmavano solo una volta, sono spariti non appena la flash è scesa a costi accettabili perché era veramente assurdo dover sostituire il micro per fare un update del software.




QuercusPetraea


x Tutti

Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV.
Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro.


Tutta questa apparente confusione deriva dal significato che diamo ai termini "alterare" e "riprogrammare" la flash.
Dalla nota applicativa AVR910, pagina 8 penultimo paragrafo, si afferma: "Per proteggere il contenuto della memoria da una sovrascrittura accidentale o da letture non autorizzate , i lock bit possono essere impostati per proteggere i contenuti della memoria ecc. ecc."
Io associo questa affermazione al termine alterare. Posso sovrascrivere parte o tutta la flash dopo aver impostato i l.b.?
No.

Più avanti la nota applicativa precisa: "Il solo metodo per riguadagnare l'accesso alla memoria dopo aver impostato i lock bits è di cancellare l'intero chip con un comando 'chip erase'. I lock bits saranno impostati ad 1, disabilitando la protezione, solo in seguito ad una pulitura di tutte le locazioni di memoria".
In questo caso il termine appropriato può essere riprogrammare. Dopo aver pulito tutta la flash, con la conseguente disabilitazione dei lock bits, posso riprogrammare la flash?
Si.

Poi si può discutere se la cosa è furba o stupida. Ma questo è un altro livello del discorso, in cui non si parla più dei lineamenti dei lock bits (cosa fanno) ma della loro efficacia (come lo fanno).

Ciao
QP


Go Up