next topic »

[Reply #405 on:]

quindi la protezione in lettura FUNZIONA!!!. Resta il mistero della protezione in scrittura. Vorrei provare da AVRDUDE, se cambio "r" in "W" dovrebbe funzionare in scrittura, no?

Si. Sostituendo :r con :w scrivi sulla flash. Esiste poi il parametro :v che permette di fare la verifica tra file.hex e flash.

Ciao
QP

AriEdit: scrittura con :w e verifica con :v

C:\Documents and Settings\tgiovanni>C:\arduino-0023\hardware\tools\avr\bin\avrdu
de.exe -C "C:\arduino-0023\hardware\tools\avr\etc\avrdude.conf"  -p atmega328p -
cstk500v1 -b 115200 -P com4 -Uflash:w:"C:\Lavoro-temp\flash.hex":i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "C:\Lavoro-temp\flash.hex"
avrdude.exe: writing flash (32748 bytes):

Writing | ################################################## | 100% 3.36s

avrdude.exe: 32748 bytes of flash written
avrdude.exe: verifying flash memory against C:\Lavoro-temp\flash.hex:
avrdude.exe: load data flash data from input file C:\Lavoro-temp\flash.hex:
avrdude.exe: input file C:\Lavoro-temp\flash.hex contains 32748 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 4.64s

avrdude.exe: verifying ...
avrdude.exe: 32748 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.

-----------------------------------------------------------------------------------------------
C:\Documents and Settings\tgiovanni>C:\arduino-0023\hardware\tools\avr\bin\avrdu
de.exe -C "C:\arduino-0023\hardware\tools\avr\etc\avrdude.conf"  -p atmega328p -
cstk500v1 -b 115200 -P com4 -Uflash:v:"C:\Lavoro-temp\flash.hex":i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% -0.00s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: verifying flash memory against C:\Lavoro-temp\flash.hex:
avrdude.exe: load data flash data from input file C:\Lavoro-temp\flash.hex:
avrdude.exe: input file C:\Lavoro-temp\flash.hex contains 32748 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 4.64s

avrdude.exe: verifying ...
avrdude.exe: 32748 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.

[Reply #406 on:]

Grazie, nel frattempo avevo provato e aggiunto un EDIT....

[Reply #407 on:]

Occhio che avrdude prima cancella la flash (e forse i fuse)

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip

Prova ad inserire il parametro -D

Ciao
QP

[Reply #408 on:]

Grazie, nel frattempo avevo provato e aggiunto un EDIT....

La protezione in scrittura è intesa interna al micro, ovvero da software non puoi scrivere sulla flash, cosa normalmente possibile se non attivi il relativo l.b., stessa cosa da programmatore se prima non esegui un erase, che cancella anche i fuse,l.b. inclusi, quindi è normale che se non disabiliti l'erase da riga di comando di AvrDude il micro viene riprogrammato.

[Reply #409 on:]

Scusate, ma non vi sto capendo, quindi ricomincio dalla mia necessità. Io voglio proteggere il micro dalla scrittura, un esempio, fornisco una scheda a tizio e voglio evitare che accidentalmente tizio la sovrascriva con un banale uploading; nello stesso tempo voglio proteggerne il contenuto (si fa per dire, in realtà è ciò che dovrò spiegare presentando lo strumento HV); quindi in HV imposto i LB su "FC" che significa protezione in scrittura e lettura. Fatto, ora cosa mi succede:
NON riesco a leggere con AVRDUDE (bene!)
RIESCO a scrivere con AVRDUDE (male!).
Quindi a me NON interessa che mettendo il parametro -D non scriva, perché significa che volontariamente NON voglio scrivere, a me serve proteggere dall'incidente o dalla cattiva idea. Avevo capito che l'unico modo per "sproteggere" era il Chip_ERASE (che effettivamente riporta i LB a FF, libero), purtroppo lo stesso effetto me lo fa una banale operazione ISP o l'AVRDUDE da riga di comando.
A questo punto posso solo fare un'ultima prova: mettere il micro con Bootloader su Arduino, protetto con FE o FC e vedere se almeno via seriale mi impedisce di scrivere

[Reply #410 on:]

Il blink passa che è una bellezza, posso UFFICIALMENTE dire che la protezione da scrittura via LB è una emerita cag

[Reply #411 on:]

Il punto è che avrdude, se non diversamente specificato con -D (Disable auto erase), esegue un chip-erase ed a quel punto hai un chip vergine sul quale puoi fare tutte le scritture che vuoi.

Ciao
QP

[Reply #412 on:]

Il punto è che avrdude, se non diversamente specificato con -D (Disable auto erase), esegue un chip-erase ed a quel punto hai un chip vergine sul quale puoi fare tutte le scritture che vuoi.

Ciao
QP

Questo è chiarissimo, la cag consiste nel fatto che ti indicano una via per proteggere un micro e poi l'unico strumento che ti mettono a disposizione per lavorarci lo sprotegge d'ufficio; cioè avrei capito se di default il -D fosse attivo, ma qui entra in ballo tutto un discorso che non vale la pena nemmeno di affrontare, tanto questa è
Comunque almeno ora ho la certezza di non aver sbagliato nulla nella programmazione dei Lock Bits. Grazie per l'eccellente supporto, come sempre!

[Reply #413 on:]

Scusate, ma non vi sto capendo, quindi ricomincio dalla mia necessità. Io voglio proteggere il micro dalla scrittura, un esempio, fornisco una scheda a tizio e voglio evitare che accidentalmente tizio la sovrascriva con un banale uploading;

La protezione per la scrittura è intesa solamente ed esclusivamente contro la scrittura della stessa da parte del firmware, non esiste nessun modo per impedire la scrittura da programmatore, ed è ovvio che sia così.
Però Avrdude usato da Arduino non esegue un erase, la flash viene semplicemente riscritta dal bootloader senza nessuna cancellazione preventiva.
La stringa di comando inviata dall'IDE è la seguente:

"..\arduino-1.0.1-rc2\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P\\.\COM4 -b115200 -D -Uflash:w:C:\DOCUME~1\user\IMPOST~1\Temp\build5651456138611584630.tmp\BlinkWithoutDelay.cpp.hex:i"

Con tanto di parametro -D che inibisce l'uso dell'Erase.

Sicuro di aver fatto i test nel corretto modo ?
Adesso non posso mettermi a fare prove, a pranzo ci provo io a caricare uno sketch tramite programmatore, avrisp MKII, settando la massima protezione  della flash e vediamo cosa succede.

edit: dimenticavo, è possibile proteggere gli AVR contro la riprogrammazione hardware, basta bloccarla da fuse disabilitando la modalità ISP e Jtag, se presente, in questo modo è possibile riprogrammali solo passando per la modalità HV per poter resettare i fuse.

[Reply #414 on:]

Questo è chiarissimo, la cag consiste nel fatto che ti indicano una via per proteggere un micro e poi l'unico strumento che ti mettono a disposizione per lavorarci lo sprotegge d'ufficio; cioè avrei capito se di default il -D fosse attivo, ma qui entra in ballo tutto un discorso che non vale la pena nemmeno di affrontare, tanto questa è
Comunque almeno ora ho la certezza di non aver sbagliato nulla nella programmazione dei Lock Bits. Grazie per l'eccellente supporto, come sempre!

Il chip non viene sprotetto, nel senso che puoi accedere al codice, ma riportato ad una condizione di utilizzo senza sapere cosa c'era prima e nessuno ti può impedire di scriverci su ulteriormente.
Diversamente (chip super protetto) se fosse impedito il chip-erase il micro lo dovresti buttare via e buona notte. Non credo che la protezione in scrittura sia intesa in questo modo.

Ciao
QP

[Reply #415 on:]

Una prima risposta alla questione l.b. si trova sul data sheet:

Code:

The user can select:
• To protect the entire Flash from a software update by the MCU.
• To protect only the Boot Loader Flash section from a software update by the MCU.
• To protect only the Application Flash section from a software update by the MCU.
• Allow software update in the entire Flash.

Si parla esclusivamente di protezione da riscrittura effettuata via software dalla MCU stessa, ovvero è esclusa la riscrittura da programmatore hardware che lavora tramite ISP, Jtag e HV.
C'è da fare un paio di prove per la conferma però in linea di massima direi che se programmi tramite ISP puoi sempre riscrivere il micro indipendente dai l.b., e questo include pure lo spazio dove è allocato il boot loader, al contrario se cerchi di caricare un programma tramite bootloader con la protezione in scrittura attiva, p.e. dall'IDE di Arduino, questo non è possibile.
Per proteggere contro la riprogrammazione tramite programmatore devi disabilitare i relativi fuse, però se fai questa operazione poi sei obbligato a ricorrere alla HV per ripristinare il micro.

[Reply #416 on:]

@Mike:
vuoi un sistema sicuro per poter non riscrivere su un chip?
Te lo do io! Togli il bootloader e disattiva il pin di reset! In questo modo usando un normale ArduinoISP oppure un programmatorino ino ino come l'USBtinyISP l'utente non può più inviare nessuno sketch.

Se manca il bootloader, la programmazione seriale tramite bootloader non funziona perché il bootloader non c'è.
Se hai disattivato il pin di reset, non puoi programmare il micro con la tecnica ISP perché la programmazione SPI sfrutta il pin di reset per dare l'avvio alla programmazione.

Hai solo la possibilità di un erase ad alta tensione (ecco che torna fuori il tuo programmatore HV) altrimenti non leggi (lock bit) e non scrivi (pin di reset).

Saluti e bacia, la fattura te la mando a fine mese 

[Reply #417 on:]

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

Code:

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

[Reply #418 on:]

ma disabilitare SPIEN no?

[Reply #419 on:]

ma disabilitare SPIEN no?

SPIEN disattiva la programmazione SPI ma non la programmazione interna, quindi se c'è un bootloader in ascolto sulla seriale puoi riflashare il micro, giusto?
Fare come ho detto io un paio di post più sopra (disattivare reset e togliere il bootloader) ti mette al riparo da qualsiasi tentativo.