Il Bootloader dei Micro MSP430

Benvenuti a un nuovo appuntamento con la Rubrica Firmware Reload di Elettronica Open Source. Texas Instruments mette a disposizione il sorgente del bootloader MSPBoot in modo tale che possa essere modificato e utilizzato sui microcontrollori MSP430: i suoi vantaggi, come la flessibilità e la modularità, combinati con un ingombro ridotto, lo rendono una soluzione molto conveniente per svariate applicazioni. Vediamo una panoramica delle sue caratteristiche più salienti.

Introduzione

In informatica (e nell’accezione più generale del termine) il “Boot Loader” (BL) è il programma che, nella fase di avvio (boot) di un computer, carica il kernel del sistema operativo dalla memoria secondaria alla memoria primaria, permettendone l’esecuzione da parte del processore e il conseguente avvio del sistema. Questo termine deriva dal fatto che il processo di avvio di un computer viene chiamato bootstrap. Nell’ambito dei microcontrollori, il concetto non si discosta molto da quello appena visto, infatti, quando si programma un microcontrollore, viene utilizzato un apposito hardware (il programmatore) specifico per il particolare micro, che, il più delle volte, oltre a essere costoso, può avere altri svantaggi come i lunghi periodi di programmazione e/o le molte interconnessioni tra il microcontrollore e il programmatore stesso, perché bisogna prevedere un collegamento ICD/ISP (In Circuit Debugger/In System Programming).

Molti di questi problemi si risolvono con l’utilizzo di un bootloader, che è un programma da inserire sul microcontrollore e consente (simulando ad esempio una seriale o una periferica USB) di caricare il programma eseguibile vero e proprio sul micro senza passare attraverso un programmatore e un’interfaccia ICD/ISP. Le tipologie di bootloader sono molteplici, facendone una distinzione basata sul protocollo usato, il più utilizzato è il bootloader UART (essendo un’interfaccia comune a molti microcontrollori), cioè un micro dopo ogni reset inizia ad “ascoltare” l’interfaccia UART per verificare se ci sono dati in ingresso. Perciò, grazie al suo utilizzo, non si ha più la necessità di un programmatore ma soltanto un software per pc (facile ed economico da trovare e/o realizzare) e un cavo seriale, provvisto di interfaccia UART (Universal Asynchronous Receiver/Transmitter).

Come si può facilmente immaginare, dopo la diffusione dell’interfaccia USB sulle schede a microcontrollori, sono nati i bootloader USB che eseguono le stesse funzioni e sono molto pratici da utilizzare. Un’altra tipologia speciale di BL è quella SPI/I2C che ha un modo di funzionare simile a ogni altro bootloader ma, invece di stare in ascolto sull’interfaccia UART/USB, legge i dati da una memoria EEPROM collegata con un’interfaccia I2C oppure SPI. Questa funzionalità permette il facile aggiornamento di un software “sul campo”: infatti, è possibile collegare la memoria SPI a uno zoccolo permettendo un cambio di firmware semplicemente sostituendo un componente, dando per scontato che si deve avere l’accesso fisico alla EEPROM in questione. Un altro bootloader largamente usato è quello CAN, prevalentemente dedicato all’industria automobilistica, visto che ad oggi la maggior parte dei dispositivi all’interno di un'auto ha una porta CAN.

Grazie a questi BL è possibile aggiornare un firmware di un dispositivo senza aprire il suo alloggiamento o senza rimuoverlo dal circuito, sfruttando le specifiche di rete native dell’interfaccia CAN stessa. Si comprende bene come tutto ciò permetta di aggiornare agevolmente il firmware dei componenti delle automobili e di apportare piccole correzioni agli eventuali bug che si potrebbero presentare. Le diverse case produttrici di microcontrollori mettono a disposizione svariate tipologie di bootloader, come ad esempio quello della Texas Instruments (TI) per il micro MSP430, da non confondere con il “bootstrap loader” (BSL), che risiede nella memoria protetta (ROM o Flash) in alcuni micro. Il bootloader d’interesse a cui ci riferiamo risiede nella memoria principale del microcontrollore e utilizza come protocollo l’Inter-Integrated Circuit (I2C), ma supporta anche interfacce di comunicazione diverse; ha molti vantaggi come la flessibilità e la modularità, che combinate con un ingombro ridotto lo rendono una soluzione molto conveniente. Sul sito della TI sono disponibili, da poter scaricare, sia i sorgenti che la documentazione, accompagnando passo dopo passo il programmatore nella configurazione e nella personalizzazione del BL.

FUNZIONAMENTO DEL BOOTLOADER

Nel caso in cui si scelga di utilizzare un bootloader, come primo passo lo si dovrà scrivere nella memoria del micro come un normalissimo programma (infatti, viene inserito nella memoria di programma); una buona locazione si può considerare quella alla fine dello spazio di memoria, anche se una parte di esso deve comunque trovarsi nelle prime locazioni per permettere l’avvio del BL dopo il reset del micro. Fatto ciò, il microcontrollore può essere riprogrammato senza avere più la necessità di alcun programmatore.

Una volta che il bootloader viene inserito all’interno del micro e questo viene resettato, il BL inizierà ad “ascoltare” su una delle interfacce di comunicazione (a seconda di come è configurato, ad esempio UART, SPI, I2C, CAN) se ci sono byte in ingresso. Se i dati vengono ricevuti nel formato che si aspetta il bootloader, esso inizia a scriverli nella memoria di programma, ma visto che alcune locazioni del vettore di reset sono occupate dal codice del bootloader stesso, i dati del programma in arrivo devono essere riallocati in un indirizzo noto.

Finita la scrittura del programma in arrivo nella memoria, il BL esegue un salto all’indirizzo conosciuto e il programma che è stato salvato viene eseguito. Nel caso contrario, ovvero quello nel quale nessun dato pervenga all’interfaccia definita, dopo un periodo di tempo stabilito il bootloader esegue un salto a una locazione di memoria data, eseguendo normalmente il firmware all’interno del micro. Perciò, sintetizzando i passi generali in un bootloader, nel caso in cui sono presenti dati in ingresso, abbiamo:

  • subito dopo il reset del micro, il BL prende il controllo ed esegue un salto all’area di memoria dove è presente il proprio codice;
  • il codice presente inizia l’ascolto sull’interfaccia esterna configurata per i dati in ingresso;
  • i dati in ingresso sono scritti nella memoria di programma come se fossero scritti da un programmatore, tranne che per i primi byte (normalmente scritti nel vettore di reset);
  • infine, una volta che tutti i dati di ingresso sono stati scritti, il bootloader esegue un salto alla prima istruzione del programma ricevuto.

Questo esempio è solo uno dei modi in cui può funzionare un BL, ma ce ne possono essere altri dedicati in base al tipo di controllore. Tutto ciò ci porta all’ovvia considerazione che, nel caso di utilizzo del BL, l’eseguibile che potremo caricare sul micro dovrà essere più piccolo, visto che una parte della memoria è dedicata allo stesso bootloader.

IL BOOTLOADER DEL MICRO MSP430

Come anticipato, il microcontrollore MSP430 della TI utilizza il bus I2C, che è stato uno dei protocolli di comunicazione più comuni in applicazioni embedded per molti anni grazie al suo basso costo di realizzazione, robustezza e flessibilità. Questo è in perfetta sintonia con le applicazioni a basso costo che richiedono un semplice collegamento di comunicazione, rendendoli un abbinamento perfetto per i micro MSP430, che combinano elevate prestazioni, alta integrazione e una bassissima potenza in un’unica soluzione molto conveniente. Questi dispositivi sono equipaggiati anche con un utile “Bootstrap Loader” (BSL) che permette in modo molto semplice di fare aggiornamenti “sul campo”; personalizzabile nei dispositivi MSP430F5xx e MSP430F6xx, perché risiedente in Flash. Altre famiglie (come ad esempio MSP430G2xx e MSP430FR5xx) hanno una BSL ROM che supporta solo il protocollo UART e che non può essere modificata per l’I2C o altre interfacce. Viste queste limitazioni, è molto utile creare un bootloader che risiede nella memoria principale e possa consentire una facile implementazione dell’applicazione. Il BL scaricabile dal sito della TI e chiamato MSPBoot, ha le seguenti caratteristiche principali:

  • ingombro ridotto (da 1 a 3 settori in flash);
  • supporto opzionale per SMBus;
  • protocolli di comunicazione differenti variano in complessità e dimensione;
  • diverse opzioni che permettono diversi livelli di robustezza;
  • supporto opzionale “dual-image”;
  • sequenza di ingresso configurabile;
  • codice sorgente disponibile, personalizzabile ulteriormente.

In Figura 1 vengono riportati i livelli dell’architettura software del bootloader, in cui si evince che è stato usato un approccio modulare per permettere una facile migrazione tra i vari dispositivi MSP430 e consentire una facile personalizzazione di ogni strato. Per quanto riguarda la “routine principale” (Main), questa ha le seguenti finalità:

  • inizializzare le funzionalità di base del microcontrollore MSP430;
  • inizializzare gli altri livelli MSPBoot;
  • implementare il ciclo principale per interrogare l’interfaccia di comunicazione e i comandi.
Figura 1: Schema a blocchi semplificato del firmware MSPBoot

Figura 1: Schema a blocchi semplificato del firmware MSPBoot

In Figura 2 viene riportato il diagramma di flusso del Main, in cui si notano i vari passaggi analizzati precedentemente, dall’inizializzazione del micro alla scelta della modalità BL o applicazione. Mentre, per quanto riguarda il livello dell’Application Manager, abbiamo come funzionalità:

  • rilevamento di quando il dispositivo è in modalità bootloader o in modalità applicazione;
  • fornitura di un meccanismo per convalidare l’applicazione;
  • fornitura di un meccanismo per reindirizzare i vettori di interrupt;
  • fornitura di un meccanismo per passare dal BL all’applicazione;
  • ripristino di un’immagine valida in modalità Dual-Image.
Figura 2: Diagramma di flusso del Main

Figura 2: Diagramma di flusso del Main

Perciò, si comprende bene come il livello dell’Application Manager decida se far partire il bootloader oppure l’applicazione. Nel primo caso, la sua esecuzione si ha se viene rilevato un evento esterno o nel caso in cui l’applicazione non sia valida; mentre viene avviata l’applicazione se questa è valida e il BL non è forzato da alcun evento esterno. In Figura 3 è riportato il diagramma di flusso di quanto appena analizzato. Per forzare l’avvio del bootloader, anche nel caso in cui un’applicazione sia valida, abbiamo due strade, la prima è configurare un evento come ad esempio lo stato di un GPIO (General Purpose Input/Output) subito dopo il ripristino del micro; solo per rendere l’idea, una semplice soluzione sarebbe la combinazione di uno o più tasti da premere come avviene di solito. In ogni caso un’impostazione predefinita del firmware MSPBoot, verifica se alcuni GPIO sono bassi dopo il reset per forzare la modalità bootloader.

Questo evento può essere modificato e impostato come desiderato, modificando banalmente una funzione già preimpostata nel firmware rilasciato dalla TI. La seconda strada è quella di far chiamare l’esecuzione del BL direttamente da un’applicazione: infatti, alcune variabili del firmware (esempio StatCtrl - passwd) sono riservate e condivise tra l’applicazione e il BL, perciò per forzare tale modalità l’applicazione imposta queste variabili a dei valori prestabiliti. Una caratteristica rilevante è la convalida dell’applicazione da parte del bootloader, prima di eseguirla. Vengono implementati quattro metodi per consentire e garantire vari livelli di occupazione memoria e di sicurezza:

  • Vettore di reset: se il vettore di reset è diverso da un valore predefinito (esempio 0xFFFF), quindi è stato cancellato, allora l’applicazione viene considerata valida e viene eseguita;
  • CRC_CCITT: viene calcolato un valore di CRC (Cyclic Redundancy Check) per l’intera immagine dell’applicazione e confrontato con un valore atteso. Questo metodo di convalida è consigliato quando si utilizza un protocollo “BSLbased”;
Diagramma di flussoFigura 3: Diagramma di flusso dell’Application Manager

Figura 3: Diagramma di flusso dell’Application Manager

  • Nessuna strategia: l‘applicazione non viene convalidata e si presuppone che sia sempre valida; un evento esterno può essere utilizzato per forzare la modalità di BL ma in questo caso non è consigliabile;
  • CRC_CRC8: viene calcolato un valore di CRC (Cyclic Redundancy Check) per l’intera immagine dell’applicazione e confrontato con un valore atteso.

Questo metodo di convalida è consigliato quando si utilizza un protocollo “SMBus-based”. Si noti che i metodi di convalida possono impedire l’esecuzione di applicazioni danneggiate ma non assicurano l’integrità e la funzionalità della stessa, la cui responsabilità è dell’utente. Nel caso in cui l’applicazione non disponga di una delle precedenti funzionalità, il dispositivo MSP430 può ancora essere recuperato utilizzando una sequenza di ingresso hardware specifica. Per proteggere l’area del bootloader, la memoria è logicamente suddivisa in due sezioni distinte: area dell’applicazione (sezione scrivibile dall’applicazione utente e “redirected vector table”), area del bootloader (sezione non scrivibile dal BL e “vector table”).

La dimensione di ciascun settore è definita nel file di progetto del “linker” ed esempi che mostrano dimensioni di memoria differenti sono disponibili nei progetti scaricabili dal sito della Texas Instruments. Con riferimento alla Figura 1, l'interfaccia di memoria (Memory Interface) ha a disposizione le API (Application Programming Interface) con le quali si può programmare e cancellare l’area di memoria dell’applicazione e proteggere la zona bootloader. Infine, sempre con riferimento alla Figura 1, si nota il blocco del “Communication Interface” (CI - interfacce di comunicazione) che si occupa di ricevere e inviare dati, implementare un protocollo di comunicazione, analizzare i dati, convalidare un pacchetto ed eseguire un comando appropriato. La Texas Instruments mette a disposizione dello sviluppatore anche hardware dedicato su cui poter testare e utilizzare quanto appena visto; in Figura 4 e Figura 5 sono riportati due esempi di schede di sviluppo.

Figura 4: Scheda di sviluppo MSP-EXP430G2

Figura 4: Scheda di sviluppo MSP-EXP430G2

 

Figura 5: Scheda di sviluppo MSP-EXP430F5438

Figura 5: Scheda di sviluppo MSP-EXP430F5438

CONCLUSIONI

Come analizzato in questo articolo, grazie alle funzionalità del bootloader MSPBoot ed alla sua alta configurabilità, che lo rendono una soluzione molto conveniente per svariate applicazioni, è possibile realizzare BL personalizzati per tutte le esigenze, da poter scaricare e utilizzare sui microcontrollori MSP430. Per maggiori dettagli e informazioni si faccia riferimento al sito della Texas Instruments.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend