Home
Accesso / Registrazione
 di 

Introduzione al BDM di Freescale (Background Debug Mode)

Introduzione al BDM di Freescale (Background Debug Mode)

Uno dei principali vantaggi del Background Debug Mode BDM consiste nel fatto che si tratta di un metodo particolarmente economico per ottenere gli stessi risultati di debug che si ottengono in complessi (e costosi) emulatori. Inoltre, il sistema BDM offre anche il vantaggio che non vengono richiesti ulteriori circuiti da integrare con il microcontrollore di cui si vuole realizzare il debug. In realtà, quello che viene richiesto è l'implementazione di uno speciale hardware all'interno del microcontrollore stesso.

Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

Ovviamente, questa caratteristica introduce un fattore di costo ulteriore rispetto al microcontrollore, ma permette di ottenere dei reali vantaggi quando è necessario procedere al debug in maniera rapida (e velocizzare ad esempio i tempi con i quali dal prototipo si passa alla produzione per il mercato). In generale, possiamo dire che un'architettura in cui è incluso un BDM consiste in un pc host e in un target.

Il PC Host si interfaccia con il target, iniziando una specie di comunicazione. Un solo pin del microcontrollore è necessario per questa comunicazione - si tratta del pin BKGD, sebbene l'host richieda l'accesso anche al pin di RESET (in realtà è necessario solo per permettere all'host di effettuare un reset se si rivela necessario). Molti tool di sviluppo includono un connettore BDM che è diventato praticamente uno standard industriale. Questo connettore è caratterizzato da 6 pin, di cui due non vengono usati. I quattro pin usato sono Power, BKGD e RESET.

Il pin BKGD è di tipo open drain, ma il resistore di pull up è incluso nel microcontrollore stesso, in questo modo non sonop necessari resistori esterni. Questa configurazione permette le comunicazioni bidirezionali sullo stesso pin, sia l'host che il target sono in grado di portare a terra (GND) per asserire un voltaggio di basso livello. Questo è il pin che determina la comunicazione single-wire e che permette di effettuare il debug del microcontrollore. E' anche possibile accedere a vari tipi di memorie on chip che si basano su questo dispositivo.

Da un punto di vista architetturale, il BDM consiste in un background debug controller BDC e di un modulo di debug (DBG). Poichè il debug consiste in hardware integrato, non c'è alcun bisogno da parte del BCD di utilizzare la CPU o le sue istruzioni, permettendo ad esso di accedere alla memoria interna anche quando il programma è in esecuzione. Sia il BDC che il DBG permettono un ricco set di features che permettono di ottenere comandi di debug da utilizzare assieme alle altre funzioni interne del microcontrollore.

Caratteristiche del BDC

    - Un solo pin dedicato per il mode selection e per le comunicazioni in background (pin BKGD)
    - I registri BDC non sono localizzati nella mappa di memoria
    - il comando SYNC determina la velocità di comunicazione con il target
    - Comandi non intrusivi per l'accesso alla memoria
    - Comandi attivi per il background mode per l'accesso ai registri della CPU
    - Comandi GO e Trace1
    - Il comando background può risvegliare la CPU dalla modalità di stop o wait
    - breakpoint hardware nel BDC
    - se il BDM è abilitato l'oscillatore funziona in stop mode

Caratteristiche del DBG:

    • due comparatori trigger
    - due indirizzi e read/write (R/W) oppure
    - un solo indirizzo + dati + R/W
    • first-in, first out per la cattura di informazioni (8 word di 16 bit)
    - possibilità di cambiare il flusso degli indirizzi oppure i soli eventi dati
    • due tipi di breakpoints
    • 9 modalità di trigger
    - solo A
    - A o B
    - A allora B
    - A e B data /full mode
    - A ma non B full mode
    - Solo B
    - A allora Solo B
    - Nel range (A indirizzo B)
    - Al di fuori del range indirizzo A oppure indirizzo B

Lo scopo principale del BDC è comunicare tramite il pin BKGD, e poichè non usa alcuna locazione di memoria della mappa di memoria del microcontrollore, e nemmeno delle sue periferiche, può comunicare con l'host senza interferire con l'applicazione che in quel momento è in esecuzione sul target. I comandi sono trasferiti serialmente dal PC (o da qualsiasi altro processore host) tramite il pin BKGD grazie ad un protocollo custom

Il trasferimento dell'esecuzione di questi comandi non ha effetto sulle operazioni real time del programma anche quando esso è in esecuzione.

Ci sono vari comandi validi per il BDC (a seconda delle versioni dello stesso) che possono essere divisi in due gruppi principali:
- comandi active background mode: nessuna applicazione è in esecuzione sul target. I comandi di background implicano che l'MCU entri nel mode background active, durante il quale si può accedere ai registri della CPU e durante il quale tutte le istruzioni possono essere tracciate

- comandi non intrusivi. L'accesso in modalità lettura/scrittura è garantito dai registri dell'MCU e dai registri di stato e controllo del BDM.

Due diversi registri sono associati al BDC, il BDSCR (un registro di stato e controllo a 8 bit) e il BDCBKPT che è un registro di breakpoint a 16 bit. Il registro di breakpoint è quello che contiene l'indirizzo dei breakpoints harware utilizzati durante il debugging. Per evitare la possibilità che venga effettuato un accesso accidentale dall'applicazione in esecuzione, il registro BDSCR non è mappato nella memoria interna.

Ed ecco alcuni dettagli circa la comunicazione: due metodi possono essere usati per comunicare fra l'host e il target. Il primo è un metodo hardware (che implica l'uso del pin di RESET dopo il pin BKGD, e quando il microcontrollore entra in modalità active background). Il secondo è un metodo software, quando non vi è alcun reset iniziale del microcontrollore e quando i comandi non intrusivi possono essere trasferiti al target, permettendo l'ingresso nel modo active.
I dati sono trasferiti attraverso il pin BKGD ad una frequenza pari a 16 cicli di background, poichè è importante che l'host conosca la frequenza di clock del target (è in pratica come impostare il baud rate per una comunicazione seriale). Il tempo del ciclo di background deriva sia dal clock del bus dell'MCU o da una sorgente di clock interna ma alternativa. Entrambe le opzioni hanno i propri vantaggi e svantaggi. Usare il clock del bus del microcontrollore può fornire comunicazioni più veloci, cosa che può essere molto utile quando si programmano grandi porzioni di memoria flash. Non è raccomandabile, comunque, utilizzare questa particolare impostazione quando si effettua un debug generale del software, poichè l'applicazione che gira sul microcontrollore ha la possibilità di cambiare la sorgente del clock on the fly.

Le analogie fra JTAG e BDM sono molte, ad esempio sono entrambi disponibili sul mercato per rispondere ad uno dei più importanti requisiti per lo sviluppo software. A differenza del JTAG, il BDM non è indicato generalmente come In.circuit test sulle linee di produzione.

Reference
Freescale BDM

RICHIESTA DI CONTATTO
Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 7 utenti e 44 visitatori collegati.

Ultimi Commenti