Come descritto nelle precedenti sezioni esistono diversi metodi utilizzati per eseguire l’aggiornamento del firmware da remoto, ciascuno con i propri vantaggi e svantaggi. In generale bisogna valutare caso per caso quale tipologia utiliz- zare e, se necessario anche creare ibridi di metodologie per meglio adattarsi ai vari scenari. Di seguito analizziamo gli aspetti chiave di ciascuna metodologia facendo riferimento al nostro particolare sistema di rete mesh IPv6. Nel pri- mo caso di aggiornamento si deve implementare un boot di avvio che riceva l’aggiornamento e lo scriva direttamente sulla flash del micro. Nella nostra particolare architettura di rete, significherebbe duplicare l’intero stack proto- collare descritto nel capitolo 2 all’interno del boot. Questo comporterebbe un incremento eccessivo delle dimensioni del boot che andrebbe ad occupare cir- ca il 50% della flash, limitandone la disponibilità per l’applicazione principale. Nel caso di aggiornamento tramite swap il requisito fondamentale per l’utilizzo di questa tecnica è la disponibilità di memoria Flash nel microprocessore. L’
4.2 Tecnica di FOTA sviluppata
Figura 4.6: Suddivisione della memoria flash
STM32L151CCT6 da noi utilizzato offre 256 Kbyte di memoria che in ambi- to embedded non sono solitamente pochi. Questo potrebbe far propendere per una scelta di questo tipo. Purtroppo però, l’utilizzo di un sistema operativo e la struttura modulare del firmware comportano una dimensione di base del firm- ware senza applicativo che supera, seppur di poco, i 100kB. La scelta di questa seconda tecnica comporterebbe una limitazione a 128 kB per la size massima del software che rappresenterebbe un vincolo troppo stringente per lo sviluppo di future applicazioni o integrazione di moduli o evoluzione di protocolli. Tale restrizione risulta inaccettabile su una piattaforma che nasce proprio come mo- dulare e per poter essere impiegata in ambiti diversi. Viste le premesse e vista la presenza nella piattaforma hardware di una EEPROM esterna si è scelto di implementare un metodo ibrido tra le due tipologie. Anziché effettuare lo swap di zone di memoria interna al micro, su utilizzerà la EEPROM esterna per salvare il file binario relativo al nuovo aggiornamento che poi verrà caricato nella memoria interna in fase di aggiornamento. La ricezione del file binario a questo punto può essere effettuata nel main program, senza alcuna necessità, quindi, di interrompere la normale esecuzione dell’applicazione e con il grande vantaggio di utilizzare l’implementazione dello stack IPv6 per la propagazione dei pacchetti di aggiornamento dal border node verso i nodi periferici. In que- sto caso il Boot si occupa solo dell’interfacciamento con la memoria esterna, del controllo di eventuali errori nel file binario che si trova nella EEPROM e della sua successiva scrittura nella flash, una volta validato. In questo modo il boot può essere relativamente semplice ed occupare una zona di memoria ridotta. Lo schema di funzionamento è riportato in Fig. 4.6.
La procedura di aggiornamento proposta offre anche il vantaggio di poter implementare l’individuazione di eventuali errori di trasmissione e/o scrittura a più livelli come mostrato in Fig. 4.7. Il primo livello di controllo è imple- mentato in fase di ricezione dei singoli pacchetti che costituiscono il file binario dell’aggiornamento sia tramite il protocollo IPv6, che si occupa degli eventuali errori sul canale, sia tramite checksum a 32bit inserito in ogni singolo pacchetto
Figura 4.7: Livelli per l’individuazione degli errori
per verificare la correttezza dei dati trasmessi. Il secondo livello è implementa- to in fase di Boot, dove oltre ad essere controllato l’intero file binario salvato sulla EEPROM esterna, sempre tramite checksum a 32 bit, viene controllato, ad ogni avvio del nodo, l’integrità del firmware presente all’interno del micro- processore. Quest’ultimo controllo è stato introdotto per risolvere eventuali perdite di alimentazione durante la scrittura della flash interna che, nella pro- cedura proposta, rappresenta il momento più critico del procedimento. Infatti, se la scrittura della flash per qualche motivo viene interrotta, al riavvio del nodo il boot si accorgerà che qualcosa è andato storto e ripeterà di nuovo la procedura di aggiornamento del firmware senza incappare in loop o blocchi che causerebbero la perdita di funzionalità del nodo.
Il funzionamento generale, in caso di avvenuta ricezione dell’aggiornamento rappresentato in Fig. 4.8, è il seguente:
1. avvio del Boot;
2. il Boot controlla l’integrita del firmware sul microprocessore;
3. se a buon fine controlla, tramite flag, se deve essere eseguito un aggior- namento;
4. se deve effettuare l’aggiornamento inizializza l’interfaccia verso la EE- PROM esterna;
5. controllo dell’integrità del firmware contenuto nella EEPROM; 6. trasferimento del nuovo programma nella memoria interna del micro; 7. avvio del programma aggiornato.
4.2 Tecnica di FOTA sviluppata
Figura 4.8: Diagramma di stato per la procedura di scrittura dell’aggiornamen- to in flash dal boot
Una volta avviato il boot è necessario gestire il “jump” all’applicazione. Al programma di boot è stato assegnato uno spazio di indirizzi in ROM da 0x8000000 a 0x8001FFF ed il vector table posizionato a 0x8000000. Il pro- gramma da eseguire viene indirizzato dall’indirizzo 0x08004000 a 0x807FFFF ed il vector table posizionato a 0x8004000. Con questo tipo di indirizzamento, all’avvio, il processore esegue prima il codice precedentemente scritto (boot), poi esegue il salto all’indirizzo del codice da eseguire.
La tipologia di FOTA proprosta unisce molti vantaggi delle tipologie già utilizzate, mitigandone allo stesso tempo i rispettivi svantaggi.
Vantaggi:
• boot relativamente facile da implementare; • insensibilità alla perdita di alimentazione;
• l’applicazione principale non deve essere fermata durante l’aggiornamen- to.
Svantaggi: