Il dispositivo jtag dello sharc è un potente strumento di debug e di verifica. in questo articolo vedremo anche una piccola panoramica dei vari sistemi di debug disponibili per il testing di un’applicazione embedded.
Prima di iniziare quest’articolo è buona norma fare alcune puntualizzazioni sulle terminologie di debug in uso. BDM (Background Debug Mode) è un termine coniato dalla Motorola per individuare un metodo di debugging che coniuga aspetti hardware e software. La funzionalità di BDM richiede una porta specifica di un microcontrollore motorola, la porta BDM per l’appunto. Ogni costruttore utilizza altri dispositivi o metodologie, per esempio la porta JTAG (IBM), OnCE (sempre Motorola) e la MPSD della casa costruttrice Texas Instruments. Il fattore che accomuna questi diversi criteri è che occorre un software, residente su un host, che permette all’utente di interfacciarsi con i segnali previsti. Il processore ADSP-21161 è equipaggiato con una porta JTAG secondo lo standard IEEE 1149.1 Joint Test Action Group per sistemi di test; la logica di JTAG consiste di una macchina a stati, cinque pin di Test Access Port (TAP) e uno shift register. La tabella 1 mostra i significati di questi cinque pins.
Tabella 1: JTAG test access port (TAP) pins
È presente un pin speciale, chiamato EMU, utilizzato dall’Analog Devices non previsto dallo standard IEEE. Questo è un segnale particolare utilizzato da un ICE per segnalare quando il microprocessore ha completato un’operazione.
Figura 1: la struttura del ADSP-21161 SHARC.
Instruction register
L’ instruction register permette ad una istruzione di essere spostata nel processore. Lo scopo è quello di selezionare il test che deve essere eseguito e/o selezionare il test data register. Questi instruction register sono costituiti da 5 bit con nessun controllo di parità. Un valore binario 2#10000# è posto nel registro d’istruzione ogni volta che il TAP è in uno stato di reset. La tabella 2 mette in evidenza la lista dei codici binari di ogni istruzione.
Tabella 2: JTAG INSTRUCTION REGISTER CODES
Le istruzioni impattano il processore ADSP-21161 come definito nella specifica 1149.1. Le istruzioni opzionali RUNBIST, IDCODE e USERCODE non sono supportati dal processore. Vediamo alcuni di questi registri istruzioni proposti:
➤ EMUPMD
Questo registro è localizzato nella system unit. E’ un registro a 48 bit ed è accessibile attraverso il registro TAP. Il funzionamento è il seguente:
quando il TAP è in stato UPDATE ed è selezionato il registro istruzioni emupmd, un registro a 48 bit è da questo aggiornato. L’uso di questo registro è abbastanza interessante: è utilizzato per forzare il processore ad eseguire le istruzioni di emulazione.
➤ MEMTST
Questo è utilizzato per usi interni solo dall’Analog Device. L’uso non corretto di questo registro può provocare effetti indesiderati.
➤ EMUPX
Anche questo registro è a 48 bit ed è accessibile dall’emulatore attraverso il TAP. Quando lo stato del TAP è in UPDATE e emupx è selezionato il bit MSB di PX è aggiornato da EMUPX. L’uso del registro EMUPX è quello di trasferire i dati tra l’emulatore e il target system. Questo registro è fornito per garantire la compatibilità con l’in-circuit emulatore di SHARC e ha una profondità di 64 bit.
➤ EMU64PX
Questo registro è localizzato nella system unit. Il registro EMU64PX è a 64 bit ed è accessibile dall’emulatore attraverso il registro TAP. Quando il TAP si trova nello stato di UPDATE e emu64px è selezionato, PX è aggiornato da emu64px. L’uso del registro emu64px è quello di trasferire dati tra l’emulatore e il sistema target.
➤ EMUCTL
Questo è un registro a 40 bit ed è accessibile dall’emulatore attraverso il registro TAP. Lo scopo di questo registro è di controllare la funzionalità di emulazione del processore, quali il breakpoint, il single step o il controllo degli interrupts esterni.
➤ EMUPC
Anche questo registro è localizzato nella sistem unit. Il registro EMUPC ha 24 bit ed è accessibile dall’emulatore attraverso il TAP. La sua funzionalità è quella di catturare gli indirizzi dal Program Counter del processore. Questa informazione è utilizzata per fare il profile statico del codice utente.
Tool di debug
Vediamo in questa sezione alcuni tool hardware/software OCD (On Chip Debugger) utilizzati per il debugging di sistemi embedded.
BDM(Motorola CPU16, CPU32, ColdFire)
I BDM hanno rivoluzionato il concetto di ROM monitor e dispongono di un insieme di comandi similari. La parte hardware consiste di un modulo d’ingresso e uscita seriale, di un serial clock e di un segnale di freeze. I comandi sono posti nel chip in modo seriale per mezzo di uno stream di 17 bit. La tabella 3 mostra i comandi del BDM della famiglia CPU32.
Tabella 3: COMANDI SU BDM CPU32
Le istruzioni di single step sono implementati o per mezzo di un controllo hardware o per mezzo di un software breakpoint nel flusso di esecuzione. Esiste, poi, una istruzione software (BGND) che permette al processore di entrare in modalità BDM.
OnCE (On-Chip Emulation)
Queste interface OnCE (On-Chip Emulation) si trovano sui dispositivi DSP della Motorola. Nella maggioranza dei chips, questa interfaccia è implementata per mezzo di pin dedicati. In alcuni chip, l’engine associato alla modalità OnCE è svolta per mezzo dell’interfaccia JTAG. La porta OnCE è più complessa di una interfaccia BDM. Le prerogative dell’interfaccia OnCE includono:
➤ Modalità di uscita dal debugger
➤ Modalità di stepping e di traccia su una o più istruzioni
➤ Modalità di ingresso in debug attraverso una singola istruzione del DSP
➤ Possibilità di modifica o lettura di ogni singolo registro del microprocessore
➤ Possibilità di modifica o lettura della memoria e delle periferiche associate
➤ Possibilità di ripristinare e di salvare la corrente pipeline del chip
➤ Possibilità di fare il cosiddetto trace delle istruzioni in tempo reale
➤ Interazioni con la modalità di debug attraverso l’uso di istruzioni dedicate
JTAG debugging (PPC6xx, IBM 4xx, TI C90, Analog Devices SHARC)
Questo è stato originalmente implementato per testare tutte le connessioni di un chip e le sue interconnessioni con gli altri chip presenti sulla scheda. In seguito, è diventato un metodo per effettuare il testing di scheda e di chip. Questo è un protocollo di tipo seriale, un po’ come per tutti gli OCD. Non esiste una implementazione univoca per questo OCD via JTAG, ogni costruttore propone una sua soluzione e di conseguenza non è pensabile utilizzare un emulatore per il processore SHARC con il PowerPc della serie 600. Inoltre, utilizzare il JTAG per le richieste di debug può essere estremamente dispendioso, infatti tutti gli elementi della catena JTAG devono essere attraversati e per diverse volte. Scaricare codice utente può essere un’attività molto lenta, addirittura meno di cento byte al secondo contro 20K al secondo con altri metodi. Un altro inconveniente, per chi utilizza realizzazioni di questo tipo, si trova nel modo in cui la catena è indirizzata: è chiaro che ogni revisione del silicio comporta diversi comportamenti in termini di prestazioni. Per questa ragione il software per il debugger deve essere consapevole di questo, e il costruttore di solito risolve il problema aggiornando l’emulatore. Chiaramente, per questo è necessario utilizzare emulatori di costruttori affidabili in grado di fornire revisione sufficientemente aggiornati.
Conclusione
La nostra trattazione sul JTAG della SHARC si conclude, ma l’argomento è certamente più vasto per chiudersi in un articolo. Inoltre, come abbiamo letto, esistono diversi sistemi per aiutare il progettista hardware/software a verificare il proprio lavoro e la specifica JATG certamente rappresenta un valido aiuto, anche e si scontra con altre metodologie e proposte di ogni singolo costruttore.
