La famiglia MSP430 di Texas Instruments fa parte di una generazione di microcontrollori con prestazioni e caratteristiche molto elevate. In questo articolo affronteremo le tematiche riguardanti il debugging avanzato con tecnologia Enhanced Emulation Module, utilizzando una versione dell’ambiente di sviluppo Code Composer Studio.
Durante la realizzazione di un progetto, più o meno complesso, gran parte del lavoro viene spesso garantito alla prova di funzionamento del circuito. Per la parte hardware solitamente si usano dei simulatori che verificano le varie componenti elettroniche, mentre il software viene gestito in maniera più semplice.
Simulare il funzionamento di un listato non è complesso e la maggior parte dei tools di sviluppo mette a disposizione opportune componenti per la verifica del lavoro svolto. Può accadere, però, che i risultati non rispecchino le aspettative, obbligando il programmatore alla ricerca dell’eventuale errore concettuale compiuto in fase di sviluppo.
Figura 1: menù a tendina per l’inserimento di nuovi breakpoint.
La necessità di un debugging on-circuit
Una volta verificate sia le parti software che quelle hardware, non resta che cominciare a realizzare i test on-circuit: realizzare un prototipo, montare i componenti e caricare il firmware all’interno del microcontrollore per avviare una simulazione in ambiente reale. I sistemi che richiedono MCU solitamente vengono impiegati per la gestione di soglie o per prendere “decisioni” rispetto a parametri forniti in ingresso, per comunicare dati ad altri dispositivi, ma raramente sono impiegati per la gestione di circuiti non complessi. Proprio per queste ragioni, una volta realizzato il prototipo è difficile portarlo nelle condizioni limite di operatività per verificare se effettivamente lavori correttamente. Per esempio: se si sta lavorando al progetto di un arresto d’emergenza per un motore endotermico, un sistema che blocchi immediatamente gli organi meccanici in caso questi superino valori specifici considerati limite per la sicurezza, è improponibile verificare se il sistema di spegnimento funzioni portando il motore ad operare nella condizione limite, in quanto se la logica programmabile avesse qualche problema, probabilmente il motore ne risentirebbe istantaneamente portando tutti i tecnici in una condizione di pericolo immediato. Per gestire operazioni di questo tipo, Texas Instruments mette a disposizione degli sviluppatori un opportuno modulo, chiamato anche Enhanced Emulation Module.
Figura 2: menù proprietà del breakpoint appena inserito. I numeri nell’immagine si riferiscono: 1: azione da compiere alla rilevazione dell’evento; 2: locazione iniziale da controllare; 3: tipo di accesso da controllare, in questo caso scrittura; 4: locazione finale da controllare 5:tipo di trigger.
L’Enhanced Emulation Module
Nella famiglia in tecnologia flash MSP430 viene reso disponibile all’interno del case un chip per il debugging avanzato. L’EEM permette di operare in differenti livelli di simulazione, lasciando all’operatore la profondità del debug da affrontare. Le varie modalità rese disponibili sono:
- da due a otto hardware breakpoint;
- breakpoint complessi;
- interruzione del listato in caso di lettura/scrittura in una determinata porzione di memoria;
- protezione di alcune aree di memoria per lettura/scrittura;
- tutti i timer e i contatori possono essere interrotti;
- esecuzione dei comandi passo passo, con possibilità di saltare alcune istruzioni;
- pieno supporto di tutte le modalità a basso consumo;
- supporto del Digital Controlled Oscillator con dipendenza da temperatura e tensione.
La logica EEM non lavora in maniera “coercitiva” con il dispositivo, ciò sta ad indicare che non va a bloccare le risorse che devono essere modificate come da istruzioni del firmware, quali: registri, memoria e interrupts.
Il funzionamento dell’EEM
Il controllo degli eventi nell’EEM all’interno delle MCU MSC430 avviene mettendosi in “fase” con i segnali interni del controllore, indicanti che un possibile evento sta per accadere. Affrontata in questa maniera, la problematica è molto complessa, ma se consideriamo il caso in cui si deve scrivere un valore in una E2PROM, prima di inviare il dato all’archivio si dovrà provvedere ad alimentarlo: questo segnale è considerato dall’EEM come un dato di Trigger, quindi si avvia la procedura di debug prevista per la scrittura in memoria. Ogni blocco del sistema interessato dal Enhanced Emulation Module provvede il proprio Trigger, lasciando all’operatore la possibilità di gestirlo direttamente come un breakpoint nel firmware, o come combinazione di due o più, rilevando quindi eventi complessi. La natura dei Trigger permette di compiere tre tipi di azioni all’individuazione di un evento:
- breakpoint;
- tracciatura;
- esecuzione in sequenza.
Nel software di debug è possibile anche definire quali condizioni debbano avviare una determinata modalità di ricerca errore: la lettura, la scrittura o l’esecuzione di un dato comando. Combinando insieme due o più di queste caratteristiche è quindi possibile individuare quando un determinato valore viene scritto in una definita porzione della memoria.
I Breakpoint
I breakpoint (figura 1 e figura 2) sono degli artefici software per bloccare l’andamento di un firmware e verificare i valori dei vari registri, memorie e I/O dell’MCU in uso. In un sistema provvisto di EEM esistono quattro differenti tipi di interruzioni: address breakpoint, data breakpoint, register breakpoint, range breakpoint.
Gli Address Breakpoint
Le interruzioni ad indirizzo sono i breakpoint, più facilmente utilizzabili tra i quattro menzionati precedentemente. Quando un blocco posto sotto controllo dall’EEM va ad interessare un indirizzo preventivamente definito, il sistema di debug va a bloccare istantaneamente il clock della CPU fermando l’esecuzione del firmware. In questo momento il sistema si trova in condizione di stasi, lasciando all’operatore il tempo di verificare la circuiteria e i parametri prima di riprendere l’esecuzione.
I Data Breakpoint
Un altro tipo di breakpoint, chiamato breakpoint dati, può essere configurato per operare con una o due sorgenti di Trigger. Un’interruzione di questo tipo può essere prodotta verificando un possibile valore (indirizzo di memoria della variabile) con il comando lettura e/o scrittura. Per affinare maggiormente la ricerca è possibile anche definire quale valore si debba attendere per avviare la procedura di interruzione. L’importante è che se si decide di utilizzare un breakpoint senza valore, allora è necessario un solo Trigger, mentre se si preferisce l’implementazione del valore si dovranno utilizzare due trigger.
I Register Breakpoint
Per i programmatori che sfruttano maggiormente le potenzialità del codice assembly, un tools molto utile e versatile è il register breakpoint che va ad interagire con i registri della CPU. Uno dei registri molto importante per il funzionamento del firmware, e che quindi deve essere controllato efficacemente, è lo stack pointer. Se viene riscontrato un malfunzionamento che permette allo stack di interagire con l’area dati, è molto difficile scovare il problema con i consueti mezzi messi a disposizione dello sviluppatore, in quanto i “sintomi” cambiano probabilmente ogni volta che il programma viene lanciato in esecuzione. Un semplice breakpoint che interrompe il funzionamento quando lo stack viene coinvolto in qualche operazione risolve l’inghippo, permettendo di identificare la procedura errata. Per un’interruzione di questo tipo viene coinvolto solamente un Trigger.
I Range Breakpoint
I range breakpoint sono necessari per verificare l’accesso ad alcune porzioni di memoria. Possono essere dei seguenti tipi:
- break on Write to Flash: questa modalità permette di individuare se durante l’esecuzione del codice qualche porzione tenti di scrivere dati all’interno della memoria flash del chip. In molte situazioni ciò non è permesso, identificando questi tentativi come errori;
- break on Read/Write to Invalid Memory: la memoria utente di un microcontrollore è definita all’interno di un certo range di Se si sfora questa porzione, si tenta di accedere a parti non libere per il programmatore incorrendo in un errore. L’EEM è in grado di rilevare problematiche di questa entità, ed in caso di impiego di segnalarle tempestivamente al software di sviluppo, permettendo all’operatore di apportare le modifiche necessarie;
- break on Instruction Fetch out of Range: un firmware fonda il suo funzionamento nei salti incondizionati tra istruzioni. Nel caso il programma eseguisse un salto al di fuori delle istruzioni, la CPU non troverà più informazioni da processare, bloccando l’andamento del listato e quindi l’esecuzione dello stesso. Un breakpoint del tipo appena descritto permette di fermare immediatamente il codice avvisando l’utente dell’esecuzione di un salto fuori range;
- break on Data out of Range: la procedura di debug è in grado di avvisare se il valore dei dati presenti nel bus sono superiori o inferiori ad un preimpostato parametro inserito nel Per l’utilizzo del sistema in questa modalità è necessario l’impiego di due Trigger, uno impostato in Read/Write nel bus, mentre l’altro programmato per il confronto dei valori. Così facendo, qualsiasi valore compaia nel data bus, sia esso un dato o un istruzione da eseguire, superiore o inferiore al limite definito, può arrestare l’esecutivo della CPU.
La Tracciatura
Si è visto come l’utilizzo di breakpoint possa agevolare la ricerca di un errore, e che se anche molto utili e di rapida implementazione, spesso non sono molto idonei al lavoro che ci si appresta a fare. La tracciatura viene utilizzata per salvare le informazioni degli indirizzi e dei dati che scorrono del data bus, e alcuni flag relativi all’istruzione che la CPU sta eseguendo. La tracciatura rende disponibili il controllo simultaneo di otto parametri, registrandone andamenti e valori in un apposito Trace buffer, disponibile al programmatore per la verifica dei valori in gioco.
La configurazione d’avvio
Una configurazione ottimale della tracciatura risulta quando si è riusciti a salvare l’istruzione da controllare per alcuni cicli. Per abilitare ciò, selezionare Trace ed abilitare il buffer, per procedere all’immagazzinamento dei dati anche dopo qualche giro di clock. Il risultato è sempre disponibile nella Trace Control windows, ed è possibile aggiornare la finestra durante l’esecuzione del firmware.
Tracciatura Real-Time
Una speciale configurazione nel menù descritto in precedenza permetterà l’implementazione della tracciatura real-time. Per un corretto funzionamento è necessario che un Trigger venga impostato in modalità lettura/scrittura variabile, in modo che qualsiasi cambiamento nel parametro sotto controllo possa creare una traccia nella finestra di dialogo. Vista la difficoltà che ho riscontrato per poter avviare una tracciatura, ritengo utile inserire una lista dei passaggi da eseguire:
- impostare il Trigger in modalità lettura/scrittura variabile, nel menù Breakpoint (attenzione disabilitare il Break per questo Trigger, altrimenti ad ogni individuazione verrà interrotto anche l’esecuzione del firmware nella CPU);
- nella finestra Trace, bisogna impostare i seguenti settaggi: Buffr wrap around e Storage trigger at Triggers.
La gestione del Clock
La maggior parte dei microcontrollori, microprocessori e degli integrati programmabili per operare scandiscono le proprie istruzioni mediante appositi cicli di clock. Maggiore è la frequenza, maggiori sono le operazioni che questi riescono a compiere in un secondo. Nell’implementazione circuitale è molto importante trovare una frequenza che non sia troppo elevata, operazioni compiute troppo rapidamente, o che non sia troppo lenta, inadatta al sistema in uso. Certo, una velocità di lavoro elevata può sempre essere rallentata mediante l’utilizzo di istruzioni senza senso, ma si deve sempre ricordare che la memoria programma ha un limite, e l’utilizzo insensato di istruzioni atte a rallentare l’esecutivo possono sempre creare problemi. Una parte molto importante nel debug di un firmware è la possibilità di gestire da remoto il clock. Con questo tools, il clock può essere stoppato o emulato, ed in modo particolare quello della CPU. Molte applicazioni, come la UART e il PWM, sono strettamente legate alla corretta impostazione di una frequenza idonea, in quanto un errato calcolo potrebbe generare ricezione di dati errate, o danneggiare la parte di potenza di un controllo Pulse-Width Modulation. Per operare variazioni alla frequenza, anche con il programma in esecuzione, basta recarsi nel menù: Project ® Properties ® TI Debug Settings ® Target Tab ® MSP430 Properties ® Clock control.
Le compatibilità
La famiglia MSP430 raggruppa al suo interno un elevato numero di dispositivi. Non tutti sono pienamente compatibili con gli artefatti per il debug, e per riassumere brevemente e verificare se un IC è impiegabile nella ricerca avanzata degli errori, basta confrontare la sigla con le specifiche della tabella 1. Le “x” che compaiono al posto del nome completo riassumono tutte le sottofamiglie aventi le diciture espresse prima e dopo la “x” stessa.
Tabella 1: la tabella prende in esame tutte le caratteristiche per il debug descritte nell’articolo, specificando le compatibilità con i vari
Conclusioni
L’EEM di Texas Instruments è un bel passo in avanti con l’implementazione tecnologica di sistemi per il controllo a la verifica delle operazioni. L’evoluzione in questo ramo sta spingendo gli ingegneri all’utilizzo di interfacce progettate prettamente per controllare il funzionamento di sistemi a sè più complessi, individuando e segnalando all’utente eventuali problemi o porzioni di sistema non conforme. L’ambiente di sviluppo Code Composer Studio si integra a pieno con le potenzialità offerte dall’interfaccia nelle MCU, solamente il posizionamento di alcuni tools nei menù dovrebbe essere reso raggiungibile più intuitivamente.
