Aggiorna ARM via etere

Creeremo una scheda ARM con un modem GSM integrato.
Vogliamo essere in grado di aggiornare il firmware ARM via etere.

Esiste una soluzione valida, affidabile e open source per questo?
In caso contrario, esiste un sistema operativo a pagamento con questa funzione?

wireless arm firmware

— hotips
fonte

ARM è piuttosto generico: ci sono molti produttori che incorporano architetture ARM e alcuni di essi possono fornire tale funzionalità.

— clabacchio

Sarebbe utile avere informazioni più specifiche su quale chip / famiglia ARM intendi utilizzare. Molti se non tutti i microcontrollori Cortex-M supportano la scrittura su flash dal codice utente. Esistono implementazioni open source di esempio, come il bootloader Maple leaflabs.com/docs/bootloader.html , e penso di aver visto l'aggiornamento del firmware su un collegamento radio supportato in alcuni quadricotteri.

— Thorn,

Al momento non abbiamo scelto il dispositivo ARM;)

— hotips

Il grosso problema con gli aggiornamenti del firmware è come forzare il chip in modalità di aggiornamento una volta che c'è qualcosa di sbagliato nel firmware. Quando hai accesso al chip puoi resettarlo e forzare un pin del bootload in alto, ma come hai intenzione di farlo via etere? L'unica soluzione affidabile che posso immaginare è avere un secondo chip (non aggiornabile) che gestisce la comunicazione di base e può aggiornare il chip principale. Dopo aver risolto quel problema, il bootloading effettivo può essere semplice come usare (ad esempio) il bootloader integrato nel chip (ad esempio, gli UPC di LPC che conosco hanno tutti un bootloader seriale).

— Wouter van Ooijen,

@Hernan Ciò renderebbe possibili sottili modalità di errore, come un chip (che in qualche modo esegue il codice sbagliato) mantenendo l'altro in reset. L'unica soluzione davvero affidabile è mantenere le funzioni in un chip così semplici da non doverle mai aggiornare.

— Wouter van Ooijen,

Risposte:

Non sono a conoscenza di soluzioni preconfezionate, ma descriverò come l'ho aggirato in un progetto. Non è del tutto "non percorribile" ma non sono consapevole del fatto che fallisca nel corso di migliaia di aggiornamenti. Per questa applicazione un tasso di guasto molto basso sarebbe comunque più economico rispetto al fatto di dover accedere alle unità.

All'applicazione principale sono stati aggiunti tre tipi di pacchetti aggiuntivi al normale protocollo di comunicazione che include il rilevamento degli errori e una strategia di tentativi in alto:

Un comando di aggiornamento del firmware iniziale cancella un'area di memoria riservata in un Flash SPI esterno. Restituisce un errore se l'unità è alimentata dalla batteria di backup o se è alimentata da alimentazione esterna ma lo stato di carica della batteria è inferiore al 25%.
Un comando di blocco in scrittura accetta un indirizzo di offset e dati scritti nella memoria Flash esterna in piccoli blocchi. Il protocollo di livello superiore si occupa del rilevamento degli errori e delle ritrasmissioni. Dopo aver scritto ogni blocco, questo viene riletto e verificato prima che il comando venga riconosciuto.
Un comando di aggiornamento del firmware di fine include la lunghezza che il firmware ricevuto deve essere insieme a un CRC32 dell'intera immagine per un'ulteriore verifica. Se questo corrisponde al contenuto della memoria Flash esterna e le condizioni di alimentazione sono ancora OK della stessa lunghezza e CRC32 viene trasferito in un'area EEPROM insieme a un "numero magico" per indicare che è in sospeso un aggiornamento del firmware.
Nell'applicazione principale viene eseguito un hard loop per forzare il riavvio del watchdog.
Il bootloader (che si trova in un'area protetta dalla scrittura di ARM's Flash) vede il numero magico in EEPROM e verifica ancora una volta il CRC32 dell'immagine. Se tutto è a posto, trasferisce l'immagine dal flash esterno nell'area principale del programma del flash ARM.
Le informazioni di aggiornamento in sospeso vengono cancellate dalla EEPROM e un hard loop forza un altro riavvio. Questa volta il bootloader avvierà normalmente l'applicazione principale.

Anche se non ho mai visto la fase di aggiornamento fallire nel testare le nuove versioni del firmware prima della distribuzione è fondamentale usando questo metodo. Se una nuova versione non è in grado di connettersi alla rete GSM e accettare futuri comandi di aggiornamento, richiederà un aggiornamento del firmware in loco.

— PeterJ
fonte

Stai usando Linux o RTOS o bare metal? Se si utilizza Debian è possibile acquisire un'istantanea del file system corrente, eseguire un aggiornamento tramite "apt-get", quindi conservare o ripristinare le modifiche a seconda che funzionasse o meno.

— bass bass
fonte

Abbiamo Linux e bare metal a seconda dell'applicazione ;-)

— hotips

Se hai Linux, puoi sfruttare gran parte di tale infrastruttura. Il modo in cui gestisco gli aggiornamenti sul mio progetto attuale è quello di creare file .deb per le applicazioni personalizzate, quindi utilizzare apt-get update per aggiornare il sistema. Sto anche sperimentando btrfs. Quel file system ti consente di scattare istantanee. Quindi il mio piano è di creare un'istantanea delle directory desiderate, provare ad aggiornare e, se non ha funzionato, ripristinare l'istantanea. Se usi il bare metal, probabilmente dovrai scegliere il solito approccio a doppia memoria, un'immagine per l'ultimo codice funzionante e un'altra per il codice appena scaricato.

— Fred Basset,