Il debugging di applicazioni embedded

Quali sono i limiti e le considerazioni da tenere presente quando si decide di fare il troubleshooting di un sistema embedded? E se poi la nostra applicazione risultasse integrata in un real-time kernel? In questo articolo cerchiamo di fare alcune considerazioni su come condurre sessioni di debug utilizzando la strumentazione a nostra disposizione.

Una sessione di test deve essere appositamente pianificata prevedendo tutti i possibili limiti o problemi che si possono presentare, in special modo, quando si deve condurre un’attività di verifica sul software embedded. In definitiva, occorre predisporre un’apposita metodologia per affrontare una sessione di test. Questa sessione è tanto particolare quanto più il sistema stesso non è corredato da un tool di debug o, ancora meglio, quando il tool non è stato acquistato per ragioni commerciali. L’utilizzatore di sistemi embedded ha una serie di strumenti a sua disposizione: da soluzioni commerciali a strumenti open, da sistemi costruiti come custom a metodologie che devono essere messe a punto a fronte di una serie attività preliminare.

Utilizzare sistemi  Open

Tra i  sistemi open sicuramente OpenOCD è uno strumento estremamente versatile, il  sistema è stato messo a punto da Rath per interfacce TTY e GDB (il  glorioso ambiente di debug della GNU). OpenOCD utilizza le prerogative già presenti su ARM (il microprocessore utilizzato da Rath): l’interfaccia e il protocollo JTAG. In ogni caso esistono anche soluzioni basate su differenti microcontrollori. Esiste un limite importante a questo tool: l’interfaccia JTAG non è presente direttamente su PC. Per questa ragione è necessario  convertire  i segnali del PC (seriale, parallela o USB) a dei valori accettati da OpenOCD. Esistono in commercio differenti schedine che permettono di svolgere questa funzione, o addirittura possiamo costruirci una nostra schedina. Utilizzare un GDB server su target è un compito abbastanza semplice per OpenOCD. Un debugger server permette alla sezione host di comunicare con il target attraverso un particolare protocollo chiamato RSP (Remote Serial Protocol), un protocollo orientato alla gestione dei messaggi.  I mezzi trasmessivi  utilizzati da questo protocollo sono diversi: da connessioni TCP alle banalissime seriali RS232. Il debugger GDB è un tool estremamente potente e utilizzato in ambiente embedded; è possibile controllare l’intero flusso di esecuzione di un programma attraverso l’uso di breakpoint o di esecuzioni in singola traccia, è possibile controllare l’evoluzione di ogni singola variabile o visualizzare e modificare locazioni di memoria. In questa configurazione la parte server del debugger è svolta da OpenOCD: in pratica l’host, o GDB client, comunica con la parte server (OpenOCD) secondo il protocollo RSP per condurre le sessioni di test. È chiaro che con OpenOCD, come server, si utilizzata sempre la porta JTAG: i comandi, che da lato host sembrano complessi (per esempio inserir e un breakpoint in memoria), si traducono in una serie di comandi inviati al processore attraverso JTAG. Forse qualcuno si ricorderà dei microprocessori Motorola 68332 o 68360 e l’uso, allora, abbastanza avveniristico delle soluzioni basate su BDM. I  processori ARM, ARM7 o ARM9, dispongono di un’interfaccia particolare che consente di sopperire a varie funzionalità di debug: Embedded-ICE. In questo modo è possibile, con la nostra applicazione su memoria non volatile, svolgere sessioni di test e utilizzare le prerogative di breakpoint sul codice senza per questa ragione ricorre a spese, a volte, non indifferenti. È chiaro che per utilizzare un circuito del genere è necessario costruirsi una piccola scheda di interfaccia con una serie moduli software per sopperire alle varie attività di test.

Utilizzare un ICE (In-Circuit Emulator)

Un ICE racchiude in sé diverse componenti. È soprattutto una scheda con dei moduli software a corredo, sia sulla scheda stessa che su ambiente host, per condurre sessioni di test hardware e su software embedded. Uno strumento di questo tipo è sicuramente di enorme aiuto, ma, viceversa, risulta essere una soluzione abbastanza costosa. Un ICE è, grosso modo, una scheda hardware con un probe. Il probe è una piccola scheda che contiene il microprocessore stesso sotto test. Il probe deve essere piazzato sulla scheda target semplicemente sostituendo la CPU, per questa ragione il codice dell’applicazione embedded è posto in esecuzione senza problemi. Il sistema ICE deve essere, poi, corredato da una serie di moduli software. L’uso di un sistema di test di questo tipo permette di guadagnare in termini di prestazioni. Attraverso un ICE è possibile monitorare le linee dati e di indirizzo in questo modo diventa possibile costruire breakpoint particolari. Per esempio, è possibile definire un breakpoint, quando un definito indirizzo di memoria è acceduto quando un determinato valore (monitorando la linea dati) è scritto (o letto). Inoltre, l’ICE dispone di una memoria privata che, attraverso una serie di direttive, è possibile mettere a disposizione dell’ambiente target. Vale a dire che, in questo modo, è possibile discriminare porzioni di memoria target e porzioni interne (di ICE), per questa ragione, è permesso di forzare, da parte dell’ICE, gli accessi da esterni a interni (magari perché si sono scoperti problemi di accesso alle memorie del target). È possibile, inoltre, monitorare ogni ciclo di CPU. In questo modo diventa fattibile costruire dei buffer interni al sistema di test per controllare, in esecuzione,  il comportamento del software sotto test. In questo modo, con la possibilità di registrare su una porzione di memoria privata (buffer) un certo numero di istruzioni, è possibile visualizzare la storia di una determinata sequenza di istruzioni in un particolare intervallo di temporale. Questo ambiente, poi, dispone anche di un’altra interessante prerogativa: un apposito linguaggio per trasferire  i comandi utenti ai diversi moduli presenti. Un linguaggio di questo tipo ha una particolare sintassi, così con questa sequenza:

WHEN ADDRESS >= 102 && ADDRESS <=

204 && DATA > 9 && DATA < 12 THEN BREAK

si definisce un breakpoint che è attivato quando si accede ad un intervallo di indirizzi (da 102 a 104) e con un valore compreso tra 9 e 12. In definitiva, utilizzare un hardware esterno, insieme con una serie di moduli software di supporto, è una soluzione che dà indubbi vantaggi, anche se i costi aumentano considerevolmente: in questo caso è necessario, come sempre, stabilire il giusto compromesso. Un sistema di test del genere permette di scoprire le cause, per esempio, di un crash periodico di sistema. In questo caso può essere conveniente attivare un trace, per mezzo di una serie di comandi dell’ICE, che permetta di monitorare le linee di reset. Ad ogni occorrenza di reset, l’ICE registrerà, in un buffer di memoria, gli eventi associati. Leggendo, poi, successivamente  il buffer sarà possibile determinare le varie istruzioni coinvolte e, di conseguenza,  i vari moduli software.

Sessione di test senza un In-Circuit Emulator (ICE)

A volte, però, non è possibile utilizzare un sistema di test con hardware integrato. Può succedere, infatti, di avere componenti, o schede, ormai obsoleti e non più in produzione. In questo caso dobbiamo utilizzare altri approcci. Una prima soluzione è sicuramente quello di simulare porzioni di codice su host. In questo caso è necessario reperire un sistema di simulazione del nostro microprocessore. Un sistema del genere, però, non è in grado di provare i vari dispositivi  hardware presenti sulla scheda, ma in ogni caso può darci delle indicazioni di massima sulla fattibilità del nostro algoritmo. Una volta terminata con successo la nostra simulazione, possiamo mettere su memoria non volatile la nostra applicazione e vedere il suo comportamento nel mondo reale. Un approccio di questo tipo deve essere svolta in maniera incrementale: è necessario integrare piccoli moduli e verificarne il loro comportamento. In questo caso è buona norma utilizzare, se disponibili, Led o altre indicazioni sullo stato del sistema (pin) per seguire in maniera trasparente il programma. Un’altra soluzione è quella di utilizzare un piccolo monitor residente con funzioni di lettura e scrittura in memoria, downloading del codice e con possibilità di singola traccia e breakpoint. Una soluzione del genere è possibile solo se si ha una linea di comunicazione (per esempio una seriale Rs232) e una quantità di memoria per contenere  il monitor stesso. Questo monitor può essere scritto appositamente per la nostra applicazione o possiamo verificarne se esiste una soluzione open per la nostra architettura. Il  listato 1 mostra una porzione di un monitor per coldfire. Il monitor può essere testato per la maggior parte su host con un simulatore. Personalmente, anni fa ho messo a punto un monitor basato su PowerPc utilizzando la versione demo del simulatore della casa costruttrice SingleStep.

brcom
        clr.l        prec_cmd
        move.b       #2,flag_cmd
        bsr          getch
        cmpi.b       #$0d,d0
        beq          exit_brcom
        cmpi.b       #$2b,d0 +
        beq           brpls
        cmpi.b        #$2d,d0 -
        beq           brmin
        bra           syntax_err
exit_brcom
        bsr           flush_a
        rts
brpls    move.b       #3,flag_cmd
        bsr           getnuma
        move.l        d0,add_br
       bset.b         #2,twf
       ori.w          #$8000,_sr
       bclr           #$1,bkptf

       MESSAGE ‘Break on rom ‘,bmsg1234
       MESSAGE ‘at address ‘,bmsg1235
       MESSAGE_INT d0
       MESSAGE_LINE

       bra            exit_brcom

brmin                 bclr #2,twf
      andi.w          #$7fff,_sr

      MESSAGE ‘Disable Break on rom ‘,bmsg2323
      MESSAGE_LINE
      bra              exit_brcom
Listato 1 - breakpoint in ROM

Sessione di test senza un monitor

Possiamo anche realizzare un ambiente di test senza un monitor. In questo caso, se fosse disponibile una Rs232, possiamo basare la nostra applicazione di debug sulle funzioni di I/O, come printf con sequenze di inline breakpoint. Non si tratta delle modalità di inline breakpoint presenti in ambito Intel o PowerPc. Nel caso Intel è possibile richiedere un breakpoint inline attraverso l’istruzione asm { int 3 }, o con PowerPc con un’istruzione di trap o system call, sc n. Il concetto di inline breakpoint è abbastanza semplice e il listato 2 mostra un esempio.

void Inline_Breakpoint(int x)
{
       int cmd;
       if (x == 0) return;
       for (;;) {
              printf(“\n > “);
              scanf(“%d”, &cmd);

              switch (cmd) {

       /* Di seguito per ogni commando ….. */
              }
      }
}
Listato 2 - inline breakpoint

La funzione di inline breakpoint è attivata inserendo la funzione “Inline_Breakpoint(x)” nelle porzioni del codice. In questo caso si associa un parametro alla funzione con una variabile globale, che può essere 0 o 1 a seconda del comportamento richiesto. Con un valore pari a 0, la modalità di debug è disattivata, viceversa con 1. L’idea è di inserire la modalità di inline breakpoint alla locazione desiderata e di cambiare il valore del parametro. Per esempio, possiamo inserire un inline_breakpoint “inline_breakpoint (pippo)” in vari punti del codice, in questo modo con un valore pari a 1 è abilitata la funzione e, al momento di ciascuna attivazione, viene eseguito il codice corrispondente.

Sessione di test con un trace  buffer

La figura 1 mostra uno schema di questa soluzione.

Figura 1: Trace buffer.

Figura 1: Trace buffer.

In pratica si tratta di inserire codice di monitoring all’interno della nostra applicazione embedded e registrare in un buffer di memoria (di ampiezza di alcuni kbyte) il flusso del programma con dei codici identificativi che segnalano in maniera univoca i vari moduli software che sono attraversati. La figura mostra un possibile codice 64 che potrebbe identificare il modulo del gestore degli eventi asincroni e con dei successivi valori che evidenziano i comportamenti  all’interno del modulo (lettura, scrittura di particolari valori di memoria).

Sistemi  SoC

Altre considerazioni possono essere fatte per le soluzioni basate su SoC. In questo ambiente l’osservazione, e le sessioni di test, condotte su un single-core può risultare insufficiente. Per questa ragione per applicazioni di questo tipo si cercano di privilegiare le attività di debugging svolte in ambito multi-core. In questo caso vanno privilegiati l’approccio dell’osservazione massima, cioè la massima tracciabilità di ciascun core e del bus interno.

 

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend