next topic »

[Reply #480 on:]

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.

[Reply #481 on:]

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.

[Reply #482 on:]

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

[Reply #483 on:]

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 ?

NON è possibile, ed infatti siamo tutti completamente d'accordo su questa cosa. Su cosa fanno i Lock Bits mi pare che QP col suo ultimo intervento abbia piantato una pietra miliare, penso che non sia più necessario spiegare altro.

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.

Anche questo è chiarissimo ed io avrò scritto parecchie volte che non aspiro a realizzare il micro bloccato per sempre, sarei stupido!
Quindi nessuno nega tutto questo, e questo era il senso delle mie affermazioni precedenti. La questione che sto ponendo e su cui orami quasi tutti sono d'accordo è che:
- L'utente standard di Arduino programma un microcontrollore o mediante IDE o mediante AVRDUDE e, nella stragrandissima maggioranza dei casi, NON è in condizione di attivare/disattivare parametri.
- Se gli consegni un micro programmato per lavorare in standalone e con i lock bit settati per la protezione in lettura (non vuoi che possa copiare il firmare) e scrittura (non vuoi che lo possa sovrascrivere accidentalmente) e lui lo collega al suo Arduino via ISP, per vedere se è vero , cosa ottiene?
a - effettivamente non riesce a leggere
b - però riesce a scrivere e fa la czzt e perde il firmware (lasciamo stare se è sciocco o meno)
e tutto questo senza fare niente di particolare, perché? perché ArduinoISP e AVRDUDE (che poi è la stessa cosa...) hanno abilitato di default il chip_erase.

Cioè TUTTO si riduce ad una sola cosa: per me è ridicolo dare la possibilità di proteggere un micro mediante programmazione e poi impostare gli strumenti ordinari di manipolazione in modo tale che la protezione venga spazzata via anche se l'utente NON lo desidera (qui non parliamo di programmatori nel senso stretto del termine, tipo il Dragon). E' come se io esco di casa, metto 4 mandate di chiave di sicurezza e poi lascio la chiave attaccata alla porta. IO NON HO DETTO CHE LA PORTA NON SI CHIUDE con questo sistema, ma solo che il sistema è inutile perché la chiave è attaccata alla porta .

Chiudo dicendo che tutta sta discussione non si sarebbe mai fatta se semplicemente si fosse mantenuto il chip erase disabilitato di default. In questo caso l'utente standard NON sarebbe stato messo in condizioni di poter sbagliare involontariamente, mentre quello più evoluto avrebbe potuto a suo piacimento attivare l'opzione chip_erase e cancellarlo.

[Reply #484 on:]

Chiudo dicendo che tutta sta discussione non si sarebbe mai fatta se semplicemente si fosse mantenuto il chip erase disabilitato di default.

Altra cosa che ti sfugge è che sebbene è possibile riscrivere la flash a singoli blocchi senza usare l'erase è il modo sbagliato di procedere nel caso della riprogrammazione, da non usarsi mai salvo casi particolari e comunque in modo ponderato.
Il comando chip erase è indispensabile prima di riprogrammare un micro, non è una carenza dell'IDE e/o di avrdude che venga utilizzato di default.
Poi se vogliamo filosofeggiare su quanto può essere "ignorante" (nel vero senso del termine) l'utente medio di Arduino, pertanto è facile che commette azioni con esiti disastrosi ed irreversibili, allora è un altro paio di maniche ed è un discorso che ha ben poco a che vedere con i lock bit 

[Reply #485 on:]

Altra cosa che ti sfugge è che sebbene è possibile riscrivere la flash a singoli blocchi senza usare l'erase è il modo sbagliato di procedere nel caso della riprogrammazione, da non usarsi mai salvo casi particolari e comunque in modo ponderato.
Il comando chip erase è indispensabile prima di riprogrammare un micro, non è una carenza dell'IDE e/o di avrdude che venga utilizzato di default.

Aggiungo, per completezza e dopo chiudo, che anche per l'auto-programmazione (Application note AVR109 pagina 3 paragrafo Page Erase) gestita dal codice del bootloader con l'istruzione SPM necessita, prima di essere effettuata, che la pagina interessata alla programmazione sia prima cancellata.
Inoltre, il comando AVRDUDE che esegue l'IDE di Arduino per programmare il micro, utilizza l'opzione -D (disabilita la cancellazione della flash) altrimenti il codice del bootloader andrebbe a farsi fott.. friggere.
Direi che non altro da aggiungere.

Ciao
QP

[Reply #486 on:]

Inoltre, il comando AVRDUDE che esegue l'IDE di Arduino per programmare il micro, utilizza l'opzione -D (disabilita la cancellazione della flash) altrimenti il codice del bootloader andrebbe a farsi fott.. friggere.
Direi che non altro da aggiungere.

Esatto, infatti è il bootloader che provvede a cancellare la flash, dato che i relativi l.b. non gli impediscono di scrivere nella application area, e sono dominanti rispetto agli l.b. della flash, può tranquillamente cancellare il programma presente.

[Reply #487 on:]

Alla fine ci siamo capiti sul fatto che la questione era puramente concettuale (o filosofica, come l'hai definita tu); mi permetto solo di riprendere una tua frase:

.... e sono dominanti rispetto agli l.b. della flash

per poter ancora di più affermare che questi L.B. sono una emerita cag , una sorta di cane da guardia che scodinzola a chiunque tenti di entrare in casa del proprio padrone, e magari gli indica pure qual è il materasso giusto 
Va bene, penso davvero che si possa chiudere ragionevolmente la questione, al solito Astro ha ragione da vendere ed io mi devo accontentare della filosofia, beh, meglio che niente
Grazie a tutti di avermi dato corda in questa squilibrata, ma spero anche utile, tematica.

[Reply #488 on:]

Andiamo in pace 

[Reply #489 on:]

Riapro per approfondire qualche concetto, visto che sto studiando il Reference del mega328P ai fini dell'articolo teorico sul Programmatore HV.

[Reply #490 on:]

ho notato che di default il bit è settato, mentre su Arduino è su 1, quindi teoricamente non dovrebbe essere possibile programmare via ISP il micro originale di Arduino.

Mi sa che stai sbagliando l'interpretazione dei fuse, su Arduino il fuse HIGH è settato a 0xDE (11011110) che prevede anche SPIEN a 0, ovvero abilitato, infatti se cambi il valore di SPIEN a 1 (disabilitato) il valore del fuse diventa 0xFE (11111110) perché cambia il bit 5 del fuse che è proprio quello del SPIEN.
Da notare che il fuse SPIEN non è accessibile da ISP, cosa voluta per evitare di settarlo involontariamente e bloccare il micro, cioè anche se disabiliti il fuse per errore non succede nulla se programmi da sketch ISP, per scrivere quel fuse devi utilizzare la programmazione JTAG (se supportata dal micro e il 328 non la prevede, la trovi sul 2560), oppure la HV.

[Reply #491 on:]

ho notato che di default il bit è settato, mentre su Arduino è su 1, quindi teoricamente non dovrebbe essere possibile programmare via ISP il micro originale di Arduino.

Mi sa che stai sbagliando l'interpretazione dei fuse, su Arduino il fuse HIGH è settato a 0xDE (11011110) che prevede anche SPIEN a 0, ovvero abilitato, infatti se cambi il valore di SPIEN a 1 (disabilitato) il valore del fuse diventa 0xFE (11111110) perché cambia il bit 5 del fuse che è proprio quello del SPIEN.
Da notare che il fuse SPIEN non è accessibile da ISP, cosa voluta per evitare di settarlo involontariamente e bloccare il micro, cioè anche se disabiliti il fuse per errore non succede nulla se programmi da sketch ISP, per scrivere quel fuse devi utilizzare la programmazione JTAG (se supportata dal micro e il 328 non la prevede, la trovi sul 2560), oppure la HV.

Sì, sì, non vedi che intanto avevo cancellato l'intervento lasciando solo la riapertura? Chiarisco: siccome sto lavorando con 6-7 file aperti, comprese alcune tabelle che ho disegnato specificatamente per spiegare il funzionamento dei Fuse, ad un certo punto ho confrontato il DE con la tabella dell'High, se ci fai caso risulterebbe proprio lo SPIEN disabilitato, allora ho scritto il post, dopo aver chiusu ho letto meglio e mi sono accorto della cxxt che avevo fatto e ho cancellato la domanda.

[Reply #492 on:]

Mi interessa approfondire due aspetti che non ho mai affrontato:
DebugWire: da quanto capisco si attiva sul pin RESET del micro e sul datasheet ci sono una serie di indicazioni su come deve essere usato (pull-up, condensatore, collegamento a Vcc), ma a cosa serve esattamente?

WatchDog: questo è un termine che ho letto diverse volte nelle discussini del Forum, se non erro a proposito dei micro che si bloccavano sulla comunicazione seriale col PC, a motivo di un errore di programmazione, ma in sostanza cosa fa e di che si occupa questa funzione?

[Reply #493 on:]

DebugWire: non sono sicuro ma dovrebbe essere un sistema per il quale puoi conoscere lo stato di registri e variabili ad ogni istante nel micro. in oltre credo tu possa simulare il clock, facendo quindi un debug passo-passo delle istruzioni asm.

WatchDog: è una specie di timer, quando raggiunge un certo valore resetta il mirco. Ovviamente tu puoi resettare quando vuoi questo timer senza far resettare il tutto.
E' utile, per esempio se la Wire ogni tanto si impalla, allora metti un watchdog per esempio a 2secondi, e ogni loop lo resetti. Nel momento in cui il micro rimane bloccato, dopo 2 secondi dall'ultimo reset il watchdog resetta il micro.

può essere pericoloso se per esempio setti tempi di reset inferiore a meno di 2 o 3 secondi: infatti il bootloader (almeno in alcune sue versioni) non spegne il watchdog, edato che il boot impiega più tempo e non resetta nemmeno il timer, il micro finisce per andare in reset infinito.
E' risolvibile riprogrammando il micro da ISP

[Reply #494 on:]

Grazie, spero di avere degli ulteriori approfondimenti, dovrei scriverci qualcosa se possibile,  e devo comprendere le problematiche più a fondo.