Topic permanente di programmazione newbie

[astrobeed]

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.

[menniti]

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

[menniti]

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

[QuercusPetraea]

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

[menniti]

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! XD

[astrobeed]

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.

[QuercusPetraea]

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! XD

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

[astrobeed]

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

Code: [Select]


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.

[leo72]

@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  XD

[QuercusPetraea]

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

Code: [Select]

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

[brainbooster]

ma disabilitare SPIEN no?

[leo72]

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.

[astrobeed]

[SPIEN disattiva la programmazione SPI ma non la programmazione interna, quindi se c'è un bootloader in ascolto sulla seriale puoi riflashare il micro, giusto?

Se è attiva la protezione in scrittura della flash tramite l.b. il bootloader non può riprogrammare il micro, avevo già fatto presente che per bloccare la riprogrammazione SPI o Jtag è necessario disabilitare i relativi fuse, dopo di che solo tramite HV è possibile riprogrammare il micro.

[leo72]

[SPIEN disattiva la programmazione SPI ma non la programmazione interna, quindi se c'è un bootloader in ascolto sulla seriale puoi riflashare il micro, giusto?

Se è attiva la protezione in scrittura della flash tramite l.b. il bootloader non può riprogrammare il micro, avevo già fatto presente che per bloccare la riprogrammazione SPI o Jtag è necessario disabilitare i relativi fuse, dopo di che solo tramite HV è possibile riprogrammare il micro.

Bene, quindi di protezioni a questo punto Mike ne ha un bel po' a sua disposizione:
- fuse SPIEN anti programmazione SPI
- fuse RSTDISBL anti pin reset
- lock bit anti scrittura bootloader (BLB0 e BLB1)

[menniti]

@ QP: io non voglio disabilitare il chip_erase, solo che non sia attivo in condizioni normali; cioè l'utente non dovrebbe poter fare una normale operazione di scrittura con successo, se ho attivato la protezione. Prendo atto che non è possibile.

@ Astro: ma un firmware all'interno di un micro è capace di gestire una autoscrittura nella flash? mi torna utile questa info per l'articolo, se me la confermi

@ Leo e BB: considerando che parlerò di stand-alone il problema bootloader non me lo pongo proprio, quindi la disabilitazione reset non mi serve; invece ok per la disabilitazione SPI, provata, l'effetto è che il micro non è sovrascrivibile via ISP(bene!) ma non è più neanche leggibile (male!) nemmeno se lascio i lock bits a FF; infatti mi dà errore di signature. Con la scusa ho capito cosa è successo a quei 2-3 chip che ho immolato per la progettazione dell'HV, a forza di sparargli botte da 12V (parlo di centinaia di volte....) devo aver danneggiato il circuito del pin reset di questi micro, e quindi è come se fosse disabilitato, perché ho provato la disabilitazione del reset e l'effetto è lo stesso: invalid device signature (quindi sia se disabilito il reset che se disabilito lo SPI).
Conclusioni, la procedura:
impostazione fuse per no SPI
lockbits su FE o FC
protegge il micro da lettura e scrittura

la procedura:
lockbits su FC protegge il micro dalla sola lettura
non c'è modo di proteggere il micro da scrittura e lasciarlo libero in lettura (condizione FE), ma comunque direi di avere una soluzione per tutto, questa particolare opzione non ha significato per me.
Naturalmente ho provato sia da IDE che da riga di comando, identici comportamenti.Grazie!