Come posso fare aggiornamenti incrementali con un flash che può essere cancellato solo in senso lato?

Scenario

Voglio aggiornare un dispositivo IoT a basso costo via etere con un nuovo firmware che aggiorna i microcontrollori del dispositivo. La memoria del microcontrollore è una memoria flash nell'intervallo da 32k a 128k (ogni centesimo conta). Questa memoria economica ha una grande limitazione: può essere cancellata solo in senso lato .

Domanda

Ciò significa che non posso effettuare aggiornamenti differenziali ( delta )? Devo sempre aggiornare l'intera memoria del controller (o almeno parti sostanziali)?

Voglio ridurre la necessità di eseguire il flash di tutto e rischiare il più completamente possibile il bricking del dispositivo. Esistono strategie esistenti quando si eseguono il flashing di microcontrollori in volo?

La semplice risposta è sì: sono necessari abbastanza blocchi di flash per supportare le immagini del codice bootloader e A / B se si desidera un'elevata affidabilità. Prima di attivare la nuova immagine, puoi scrivere tutto, verificarlo e potenzialmente riprovare.

Tuttavia questa è una strategia costosa / affidabile e ci sono cose che puoi fare per ridurre le spese generali. Il supporto di basso livello per gli aggiornamenti OTA può anche essere parte del firmware o del sistema operativo del dispositivo, quindi è possibile evitare il proprio roll-off a meno che non si desideri imparare. Questa funzione potrebbe essere descritta come FOTA.

Il partizionamento della base di codice consente aggiornamenti incrementali, nel migliore dei casi il bootloader è in grado di attivare la connessione di rete, scaricare e verificare il codice senza bisogno di alcun codice utente di fallback. Con un gateway locale, la gestione di questa attività può essere delegata dagli endpoint a basso costo.

Molti dispositivi hanno una piccola quantità di flash per la cancellazione di parole e, anche in questo caso, è possibile impostare bit senza la necessità di cancellare un intero blocco. Queste funzioni possono essere utilizzate per manipolare le tabelle di salto e ricucire il codice che viene aggiornato in blocchi di dimensioni di blocco. Anche se inizialmente hai pianificato uno spazio di codice A / B completo, potresti dover ricorrere a uno schema più complesso quando la base di codice cresce troppo.

Per chiarire la funzionalità che può essere raggiunta con una sofisticata soluzione firmware over-the-air, il bootloader e potenzialmente uno stack di comunicazione primario possono rimanere residenti mentre viene ripubblicato l'intero spazio rimanente dell'applicazione utente. Ciò non richiede alcun sovraccarico (in particolare se il partizionamento dei blocchi è morbido). Nello scenario in cui è necessario aggiornare lo stack di comunicazione, l'area generalmente utilizzata per il codice dell'applicazione può essere temporaneamente utilizzata durante il download e la verifica. Per raggiungere questo obiettivo è necessario un supporto nel SoC, ma esistono già dispositivi di seconda e terza generazione progettati tenendo conto di ciò.

Voglio ridurre la necessità di eseguire il flash di tutto e rischiare il più completamente possibile il bricking del dispositivo. Esistono strategie esistenti quando si eseguono il flashing di microcontrollori in volo?

A parte il codice che esegue l'aggiornamento che sarebbe relativamente statico, è necessario mantenere due immagini nella memoria: un'immagine attiva e un'immagine di backup. Ogni volta, è necessario aggiornare, farlo nel backup, quindi passare a essere attivo. Una volta stabile, aggiorna la vecchia immagine attiva che ora dovrebbe essere il tuo backup.

Tenendo presente ciò, è possibile utilizzare algoritmi di livellamento dell'usura durante l'aggiornamento di entrambe le immagini. Il codice per tali algoritmi potrebbe richiedere circa il 10-15% della memoria totale, ma vale la pena estenderne la durata.

Il livellamento dell'usura è in genere gestito dal controller flash, che utilizza un algoritmo di livellamento dell'usura per determinare quale blocco fisico utilizzare ogni volta che si programmano i dati. Esistono due tipi di livellamento dell'usura delle unità a stato solido (SSD): dinamico e statico. I pool di livellamento dell'usura dinamica hanno cancellato i blocchi e selezionano il blocco con il conteggio di cancellazione più basso per la scrittura successiva.

Il livellamento dell'usura statica, d'altra parte, seleziona il blocco target con il conteggio di cancellazione complessivo più basso, se necessario cancella il blocco, scrive nuovi dati nel blocco e garantisce che i blocchi di dati statici vengano spostati quando il loro conteggio di cancellazione blocco è inferiore a certa soglia. Questa ulteriore fase di spostamento dei dati può rallentare le prestazioni di scrittura a causa del sovraccarico del controller flash, ma il livellamento dell'usura statica è notevolmente più efficace del livellamento dell'usura dinamica per prolungare la durata dei dispositivi a stato solido.

( Techtarget.com: indossare il livellamento )

Freescale Semiconductor descrive un modo affidabile per l'aggiornamento del firmware over-the-air per i loro microcontroller Kinetis .

Si chiama: Program Flash Memory Swap .

Sistemi che utilizzano lo scambio di memoria flash

Nei dispositivi con due o più blocchi flash interni che supportano lo scambio, è possibile scambiare l'indirizzo di base della memoria di ciascun blocco flash. La posizione dell'indirizzo di ciascun blocco flash verrà quindi scambiata nella mappa di memoria logica del dispositivo. Dopo un ripristino, il sistema di scambio flash incorporato essenzialmente seleziona quale software esegue dalla posizione del blocco flash nella mappa di memoria logica. Ciò consente un sistema di backup del codice con l'ulteriore facilità di programmazione. È possibile eseguire da un blocco durante la cancellazione / programmazione dell'altro blocco. Sui dispositivi Kinetis, il sistema di scambio flash monitora / controlla tutte le fasi del passaggio dalla vecchia applicazione alla nuova; vi è una maggiore garanzia di funzionamento affidabile in caso di interruzione di corrente durante una di queste fasi.

vantaggi

• Facilità di programmazione. L'applicazione viene sempre eseguita dal blocco inferiore nella mappa di memoria.
• Tolleranza alla perdita di potenza.
• Nessun bootloader richiesto. Nessun ritardo all'avvio dell'applicazione principale.
• Adatto per un sistema operativo multi-tasking. Minori tempi di inattività dell'applicazione. In un sistema multi-tasking è possibile continuare a eseguire le principali attività dell'applicazione mentre sono in esecuzione attività in background per aggiornare la nuova copia dell'applicazione.
• Copia di backup del codice. È possibile ripristinare l'applicazione di lavoro nota.

svantaggi

• Spazio di memoria flash aggiuntivo necessario per memorizzare la copia di backup.

È possibile aggiornare i blocchi e quindi scambiarli.

Il documento collegato contiene una descrizione dettagliata.

Garantisce aggiornamenti del firmware più sicuri ma poiché richiede più memorie flash, sicuramente costa di più . Inoltre non applicabile per qualsiasi tipo di microcontrollore, solo quelli che supportano lo scambio di blocchi flash interni.