L’interfaccia JTAG nei micro Sharc

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

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.

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

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

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.

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend