ciao!
se il micro che si deve impiegare ha a bordo solo la flash ed è necessari o un bootloader, come lo si può rendere capace di sopravvivere ad un powe r-loss durante la fase di firmware upgrade?
secondo voi è sensata una cosa del tipo impiegare un secondo micro minusc olo che se non riceve l'ok dal micro principale entro un tot dall'accension e, prende il controllo dei pin icsp e sbatte dentro al micro principale un bootloader così che questo poi possa proseguire?
-ice-
Il 12/10/2012 21:57, ice ha scritto:
Di che micro parliamo? L'area di bootloader si può proteggere?
In generale se fai in modo di non andare a scrivere nella zona del bootloader puoi sempre recuperare una scrittura errata riavviando il micro (così che parta nuovamente il bootloader) e riscrivendo la flash. Questo è facilmente gestibile in automatico con un semplice monostabile retriggerabile.
Marco
"ice" ha scritto nel messaggio news: snipped-for-privacy@googlegroups.com... ciao! se il micro che si deve impiegare ha a bordo solo la flash ed è necessario un bootloader, come lo si può rendere capace di sopravvivere ad un power-loss durante la fase di firmware upgrade? secondo voi è sensata una cosa del tipo impiegare un secondo micro minuscolo che se non riceve l'ok dal micro principale entro un tot dall'accensione, prende il controllo dei pin icsp e sbatte dentro al micro principale un bootloader così che questo poi possa proseguire?
-ice-
----------------------------------------- Se nel bootloader ci metti una verifica tipo crc sull'area di codice sottostante (o soprastante), il bootloader stesso potra' 'sapere' se la volta prima ha scritto completamente il codice oppure no Che micro e' ? Ciao RobertoA
Il giorno venerdì 12 ottobre 2012 23:38:22 UTC+2, Marco Trapanese ha scri tto:
ancora non so di preciso, probabilmente microchip; la domanda era in generale, talvolta il micro non lo puoi scegliere e viene cmq richiesta una particolare caratteristica; mi interessava capire cosa fare se il bootblock non c'è per cui devi mett ere il codice del bootloader direttamente nella memoria programma
per i uC microchip si, la serie 18f e successive mi pare abbiano tutte il b ootblock che si può proteggere tramite un bit di lock
-ice-
Il giorno sabato 13 ottobre 2012 10:43:10 UTC+2, RobertoA ha scritto:
oppure una cella di eeprom o di flash che viene cambiata dopo che il firmwa re è stato aggiornato correttamente, così il bootloader sa se deve ripe tere o meno la procedura di update
nel caso però di micro senza area di boot dedicata, che si fa?
-ice-
Il 13/10/2012 14:58, ice ha scritto:
è stato aggiornato correttamente, così il bootloader sa se deve ripetere o meno la procedura di updatePuoi sempre scrivere il bootloader in modo che non vada a scrivere sé stesso durante l'aggiornamento. L'unico problema è quando una applicazione fake (o un bug) scrive nel bootloader... ma forse si può convivere con queste limitazioni.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.