Per soddisfare le stringenti richieste di mercato, Microchip ha sviluppato una linea di prodotti hardware e software che aiutano il programmatore a sviluppare e a testare i progetti basati su microcontrollori. Il centro di gestione di questi prodotti è l’ambiente di sviluppo integrato MPLAB Integrated Development Environment. Un sistema per il debug del firmware è uno strumento indispensabile per chiunque programmi microcontrollori. Nell'articolo si descriveranno due “colonne portanti” nell’analisi del flusso di istruzioni dei PICMicro: ICE e ICD2. Si evidenzieranno vantaggi e svantaggi dell’una e dell’altra soluzione.
Introduzione
MPLAB ICD 2 ha le caratteristiche di debugger a basso costo, emulatore e programmatore in un unico dispositivo. Le tecniche di programmazione e test di un sistema a microprocessore possono essere differenti e si suddividono sulla base di fattori quali costo, difficoltà di apprendimento e possibilità di tecniche di debug avanzate. La Tabella 1 ne riassume le principali. Nel presente articolo si approfondirà la conoscenza dei tool ICE e ICD, cercando di evidenziare le differenze esistenti tra loro.
Tabella 1. Le tecniche di programmazione dei microcontrollori si possono suddividere in base a fattori come il costo, la difficoltà di apprendimento e la disponibilità di opzioni di debug avanzate
CONFRONTO TRA STRUMENTI DI DEBUG
Utilizzando MPLAB IDE ed il suo simulatore software, è possibile scrivere e testare l’applicazione. Ma per testare sul campo il prototipo è indispensabile almeno un programmatore: un elenco completo è riportato in Tabella 2.
Tabella 2. I programmatori per PICMicro che Microchip mette a disposizione
Un programmatore semplicemente trasferisce il codice macchina dal PC nella memoria interna del micro; a questo punto il chip può essere inserito nella propria scheda e testato. Difficilmente il codice scritto sarà perfettamente funzionante a primo colpo. Anche se l’uso di MPLAB SIM può essere utile per testare il codice, spesso il firmware interagisce con gli altri dispositivi esterni in maniera non esattamente prevedibile o ancora gli eventi in real-time delle periferiche sono difficili da simulare accuratamente. Per questa ragione sono indispensabili i debugger (Tabella 3). Ci sono due tipi di debugger:
- In-circuit emulator – Utilizzano dell’hardware specializzato al posto del vero microcontrollore.
- In-circuit debugger – Utilizzano microcontrollori che hanno la caratteristica di debug incorporata.
Nella prima categoria rientrano MPLAB ICE 2000 e MPLAB REAL ICE, mentre la seconda categoria è rappresentata da ICD 2. La Tabella 4 mostra le caratteristiche distintive di questi due prodotti. Come si può notare ICD 2 è relativamente economico confrontato all’ICE (circa dieci volte minore), ma richiede, per il debug, che alcuni pin e parte della memoria programma siano occupati.
Tabella 3. Debugger/emulatori per PICMicro che Microchip mette a disposizione
Tabella 4. Caratteristiche distintive a confronto dei debugger ed emulatori ICD e ICE
L’ICE invece non riserva alcun pin o area di memoria, offre la possibilità di effettuare il trace analyzer che consente di registrare tutte le istruzioni eseguite dal micro. Per usare ICD 2 sulla propria scheda è indispensabile prevedere un connettore per il debug; se ciò non è possibile allora l’uso dell’ICE è indispensabile.
IL TOOL ICD2
MPLAB ICD 2 è uno dei componenti hardware opzionali che possono essere acquistati per eseguire il debug di un’applicazione usando l’ambiente integrato MPLAB. Il debug in-circuit (ICD) è un’alternativa economica all’emulazione in-circuit (ICE). Infatti, se un’applicazione è progettata per essere ICD-compatible, questo strumento può svolgere molte delle funzione dell’ICE. I vincoli dell’ICD sono:
- Uso esclusivo di parte dell’hardware e del software.
- Il PIC deve essere dotato di un sistema di clock (poiché l’ICD non può simularlo)
- Il debug può essere eseguito solo se tutti i collegamenti sono perfettamente funzionanti.
Un emulatore può fornire, invece, memoria e clock; può eseguire codice anche senza essere connesso alla scheda finale. In teoria, il codice può essere sviluppato anche se non si dispone ancora della board. La Figura 1 mostra i pin che costituiscono il connettore per collegarsi all’ICD 2, mentre la Figura 2 riporta le connessioni elettriche tra ICD 2 e la scheda.
Figura 1. Rendendo la propria scheda ICD-compatible si ha la possibilità di riprogrammare e testare il chip senza rimuoverlo dalla scheda.
Figura 2. Connessioni elettriche tra ICD 2 e target board
L’ICD 2 può essere comodamente utilizzato, oltre che sulle schede opportunamente realizzate, anche su tutte le board di prototipazione della Microchip. La Figura 3 mostra come interconnetterlo alla PICDEM 2, tramite l’apposito connettore.
Figura 3. L’ICD 2 può essere comodamente utilizzato su tutte le schede di prototipazione della Microchip, come la PICDEM 2
Per impostare ICD 2 come debugger bisogna eseguire le operazioni di seguito riportate:
- Selezionare da MPLAB IDE DebuggerxSelect Tool e scegliere ICD 2 MPLAB.
- A questo punto un programma per eseguire il debug è caricato nella parte alta della memoria programma del PIC. Questo implica che una parte della memoria programma non potrà essere utilizzata per le proprie applicazioni. Tipicamente sono necessarie 0x120 word della memoria programma.
- Ora è possibile programmare il dispositivo con il codice.
Gli indirizzi di eventuali breakpoint che possono essere impostati, sono inseriti nella memoria programma. Per l’installazione dei driver è necessario selezionare da MPLAB IDE HelpxDriver Installation (Figura 4) e poi scegliere MPLAB ICD 2 Release Notes. Seguire le istruzioni visualizzate nella pagina web che viene aperta.
Figura 4. Prima di utilizzare ICD 2 (o qualunque altro tool) è necessario installare i relativi driver
IL TOOL ICE
La Figura 5 mostra il kit completo del ICE 2000 di Microchip.
Figura 5. Il kit completo di MPLAB ICE 2000
Esso permette di emulare tutti i tipi di PICMicro e di eseguire le funzioni base come run, halt, step singoli e breakpoint; a queste vanno aggiunte funzioni avanzate come monitoraggio delle variabili, trace delle istruzioni e complex triggering. La Figura 6 chiarisce l’utilizzo dei vari componenti e le modalità di inserimento.
Figura 6. Interconnessione delle varie parti del kit ICE 2000
L’emulator pod è unico per qualunque dispositivo, mentre è necessario utilizzare un modulo processore ed un adattatore specifico per il PIC da emulare. Questa è un’altra fondamentale differenza rispetto all’uso dell’ICD 2, il quale è unico per tutti i modelli. Il tipo di connessione al PC è di tipo parallelo nel modello ICE 2000. Per essere certi che il dispositivo sia riconosciuto dal software MPLAB IDE è necessario installare i driver, seguendo la stessa procedura descritta per ICD 2. In questo caso sarà necessario selezionare l’opzione MPLAB ICE 2000 Release Notes, anziché MPLAB ICD 2 Release Notes. MPLAB ICE 2000 permette di scegliere la sorgente di alimentazione per il chip (emulato). Di default l’alimentazione viene prelevata dall’emulatore (5V). In alternativa si può selezionare l’alimentazione della scheda finale. Questo consente di effettuare una simulazione più realistica. Per cambiare questo parametro, selezionare DebuggerxSettings; selezionare il tab Processor Power e fare la propria scelta (Figura 7).
Figura 7. ICE 2000 permette di selezionare la sorgente da cui prelevare l’alimentazione: dall’emulatore (5V) oppure dalla scheda (da 2.0V a 5.5V)
L’ICD 2 non dispone dell’opzione di selezionare una tensione propria, ma utilizza necessariamente la tensione di alimentazione della scheda. Un altro aspetto da considerare è il clock: ICE 2000 consente di prelevarlo sia dalla scheda in test che dall’emulatore. La scelta può essere effettuata selezionando DebuggerxSettings e aprendo il tab Clock. La possibilità di scegliere il clock, non disponibile per l’ICD 2, consente di testare il firmware con differenti frequenze per il master clock. Molto comoda per il debug del firmware è la capacità di bufferizzare fino a 65536 istruzioni e visualizzarne il relativo trace. Per trace della memoria si intende un elenco di tutte le operazioni eseguite dal processore, in particolare per ogni istruzione sono visualizzate le seguenti informazioni:
- Line – Posizione relativa dell’istruzione rispetto ad un evento di trigger precedentemente impostato. Cioè si indicherà con 0 l’istruzione che ha scatenato l’evento e con numeri progressivi quelle successive; invece, per le istruzioni precedenti al trigger saranno usati numeri negativi.
- Addr – Indirizzo dell’istruzione.
- Op – Istruzione.
- Label – Etichetta (se definita) associata con quell’indirizzo di memoria.
- Instruction – Istruzione in linguaggio assembler.
- SA (Source Data Address) – Indirizzo del dato sorgente (se previsto).
- SD (Source Data Value) – Valore del dato sorgente (se previsto).
- DA (Destination Data Address) – Indirizzo del dato di destinazione (se previsto).
- DD (Destination Data Address) – Valore del dato di destinazione (se previsto).
- Cycle – Valore progressivo dell’istruzione espresso in esedecimale (fino a 65536).
- Probe n – Stato logico delle sonde esterne.
L’ICE 2000 dispone di un meccanismo di trggerring potente e flessibile. Per trigger si intende una combinazione di eventi che può causare un breakpoint hardware o l’inizio della cattura delle istruzioni nella finestra del Trace. Per impostare queste opzioni è necessario selezionare DebuggerxComplex Triggers and Code Coverage, poi scegliere il tab Complex Trigger Settings. Per meglio comprendere l’utilità dei complex trigger si farà un esempio pratico di utilizzo. Si supponga che un flag bit venga settato in maniera errata da qualche parte nel codice. La domanda è: in quale punto si verifica questo evento? Per scoprirlo si può impostare un trigger sulla memoria dati. Si supponga che questo bit sia il terzo contenuto nella variabile Flags. L’evento deve scattare solo se questo bit diventa 1. Per questo sarà sufficiente impostare Sequential Trigger, Write e Data Memory; poi specificare l’indirizzo Flags come in Figura 8.
Figura 8. Un trigger è una combinazione di eventi: breakpoint hardware o cattura con il trace
A questo punto è possibile avviare l’esecuzione del firmware e appena il bit viene impostato ad 1 l’esecuzione sarà arrestata e tramite il trace sarà possibile risalire alla porzione di codice che l’ha modificato.
Vi consiglio anche di dare un’occhiata anche a https://it.emcelettronica.com/debuggerprogrammer-mplab-icd-2-recensione . Sul sito della microchip trovate la versione 3
L’ICD2 è oramai obsoleto ed è stato sostituito da anni dall’ICD3, anche se poi per chi lo uso le differenze non sono sostanziali (ad esempio il pin out illustrato sopra è lo stessi).
L’ICE 2000 invece è più che obsoleto e oramai non danno neanche più supporto tecnico. E’ molto comodo perché non c’è bisogno di dedicare 3 pin del micro per il debug, come con gli altri emulatori, ma oramai è da anni che la Mirochip lo ha abbandonato come sistema di sviluppo.
Oltre a quanto già scritto nell’articolo da un po’ di anni c’è anche il PicKit3: simile al PicKit2, economico e molto funzionale!
Buongiorno Luca
purtroppo ho ancora ICD2 che ho rispolverato per un progetto fatto da altri, ho pc AMD con w7 64 bit e ho bisogno di sapere come trovare i driver per MPlab 8,92.
Eventualmente ho anche un altro hd con sistema operativo window 7 prof 32 bit.
Grazie.
Paolo F.
[email protected]
Sto vedendo che sul sito della Microchip effettivamente non si trovano più riferimenti all’ICD2 (obsoleto ormai da tempo).
Hai provato a fare una ricerca su internet? Forse qualcosa si può trovare.
Io purtroppo non ce li ho installati sul mio PC.