Debug dei protocolli seriali con un oscilloscopio

Confronto tra oscilloscopio e analizzatore logico

Quando si necessita di un decodificatore di protocollo, si potrebbe utilizzare un oscilloscopio, un analizzatore logico o un analizzatore di protocollo dedicato. Ma quale di questi strumenti ha più senso? Ecco un breve confronto tra i tre strumenti.

I canali dell'analizzatore logico sono essenzialmente comparatori digitali. Pertanto, possono solo dirvi se un segnale è alto o basso. Gli analizzatori logici tipici hanno almeno otto canali, con alcuni modelli che ne offrono 32 o più. Gli analizzatori di protocollo sono simili agli analizzatori logici, ma dispongono di hardware e software specifici per il protocollo per decodificare il collegamento seriale.

Gli oscilloscopi, invece, hanno una risoluzione di molti bit, ma sono in genere limitati a due o quattro canali. La maggiore profondità di bit consente di vedere le caratteristiche analogiche dei segnali.

Fortunatamente, con gli oscilloscopi moderni, raramente è necessario scegliere una di queste tre opzioni. Molti oscilloscopi, compresi tutti i modelli Rohde & Schwarz, offrono canali logici, sia analogici che digitali. Tali oscilloscopi sono chiamati "oscilloscopi a segnale misto" (MSO).

Alcuni oscilloscopi dispongono persino di strumenti di decodifica del protocollo per i bus seriali! Ad esempio, i modelli R&S®RTB2000, R&S®MXO 4 o R&S®RTO 6 sono dotati di decodifica del protocollo e trigger integrati per i protocolli seriali più frequentemente utilizzati.

L'oscilloscopio brilla soprattutto quando viene rilevato un errore di protocollo. Un canale analogico (o più canali) che campiona il bus può mostrare se c'è un problema analogico al momento dell'errore di protocollo (o intorno a questo). Questa situazione è raramente osservabile con un analizzatore logico.

Poiché esistono molti protocolli seriali e il loro supporto varia a seconda del modello di oscilloscopio, ecco alcune note e trucchi per il debug dei circuiti che utilizzano i bus più comuni.

UART

Il ricevitore/trasmettitore asincrono universale (UART) è talvolta chiamato anche "seriale". I segnali di trasmissione e ricezione sono fili senza clock discreto. È un sistema punto-punto, il che significa che di solito sono collegati solo due dispositivi.

In alcuni casi, l'UART è il sistema più semplice di cui eseguire il debug, perché è sufficiente esaminare almeno un segnale: TX (trasmettitore) o RX (ricevitore). Tuttavia, nella pratica, è generalmente necessario vedere entrambe le direzioni per comprendere la comunicazione.

La comunicazione via UART ha un metodo di framing flessibile. Sono presenti un numero variabile di bit di avvio e di arresto e un bit di parità opzionale. Il carico di dati è in genere di 8 bit. Poiché un collegamento UART è asincrono, l'host e il dispositivo devono concordare questi parametri e la velocità di trasmissione. Gli stessi requisiti si applicano a un oscilloscopio durante il debug.

Nota: i decodificatori di solito permettono di cambiare la velocità di trasmissione dopo la cattura. Regolare questa impostazione se la decodifica non è corretta. Altrimenti, non si sarà in grado di decodificare (o eseguire il trigger) correttamente.

SPI e QSPI

Il bus SPI o S-P-I è noto come "interfaccia periferica seriale". Funziona come un registro a scorrimento. Tutti i dispositivi condividono il clock, i segnali di uscita principale e di ingresso secondario (MOSI) e i segnali di ingresso principale e di uscita secondaria (MISO). Questi corrispondono a "TX" e "RX" di un collegamento UART. Tuttavia, sono espliciti nella direzione in cui si muovono i dati. Ad esempio, con MOSI i dati vanno dall'host al dispositivo, mentre con MISO i dati vanno dal dispositivo all'host. Questo rende meno probabile acquisire il segnale sbagliato!

Il protocollo SPI supporta più dispositivi collegati sullo stesso bus. Ogni dispositivo dispone di un segnale di chip select (CS) per differenziare i dispositivi. Tuttavia, i progetti con un solo dispositivo SPI possono omettere (o abilitare sempre) il segnale CS. Analogamente, se i dati vanno in una sola direzione, è necessario collegare solo il segnale MOSI o MISO appropriato.

La stessa idea vale per il debug con un oscilloscopio. Se sul bus è presente un solo dispositivo, non è necessario collegare una sonda al segnale CS. E se i dati si muovono in una sola direzione, la maggior parte dei decodificatori è in grado di gestire un'unica sonda. Il segnale di clock, tuttavia, è sempre necessario.

Cos'è il bus QSPI?

Uno standard di interfaccia prevalente per i chip di memoria flash è il protocollo quad SPI (QSPI). Come SPI, dispone di un pin di clock, di abilitazione e di dati.

Inter-Integrated Circuit (I2C)

Il bus Inter-Integrated Circuit (I²C) è stato originariamente sviluppato da Philips, successivamente confluita in NXP. A volte i dispositivi che supportano I²C utilizzano il nome "a due fili" per evitare problemi di marchio o di licenza.

Tutti i dispositivi sul bus condividono le linee di clock e di dati e ogni dispositivo deve avere un indirizzo univoco. In generale, i sensori o i dispositivi che utilizzano il bus I²C avranno un indirizzo di base con alcuni bit per impostare i bit meno significativi del loro indirizzo. Questa tecnica è utile quando si hanno più sensori dello stesso tipo sul bus con un numero minimo di pin.

Per il bus I²C, il debug sull'oscilloscopio richiede due canali. Il clock funziona solo quando l'host comunica con un dispositivo. Pertanto, l'oscilloscopio deve acquisire sia i segnali di clock che quelli di dati.

I²C: a 7 o 8 bit (o a 10 bit)

Gli indirizzi I²C possono creare confusione a causa delle due diverse modalità di indirizzo: a 7 bit e a 10 bit. La modalità a 7 bit è più comune, ma ha una caratteristica che crea confusione: a volte viene considerata un indirizzo a 8 bit!

La confusione deriva dal bit R/W che viene dopo l'indirizzo. Per le transazioni di LETTURA, il valore è "1". Per le transazioni di SCRITTURA, il valore è "0". Pertanto, se il triggering non riesce sull'indirizzo previsto durante il debug di I2C, provare a spostare l'indirizzo di un bit a sinistra e includere il valore R/W.

Bus CAN

La rete Controller Area Network (CAN) è stata sviluppata per l'uso nelle automobili e continua a essere molto utilizzata nell'industria dei trasporti. La segnalazione differenziale migliora l'immunità ai disturbi elettrici, rendendola ideale per le applicazioni industriali.

Pur essendo differenziale, nella maggior parte dei casi non richiede una sonda per oscilloscopio differenziale. Invece, una sonda single-ended collegata al segnale "CANH" o "CANL" è sufficiente per far sì che il decodificatore dell'oscilloscopio decodifichi il bus.

Esistono due versioni CAN 2.0: di base (indirizzo a 11 bit) ed estesa (indirizzo a 29 bit). I loro frame di dati sono leggermente diversi nei campi di arbitraggio e di controllo, ma per il resto i loro pacchetti sono uguali.

Il bus CAN utilizza solo due fili di segnale, nessuno dei quali è un clock. Pertanto, se una decodifica sembra confusa, provare ad adattare il punto di campionamento, per cambiare dove il decodificatore campiona i dati.

Confronto tra decodifica e trigger

La decodifica è un metodo di post-elaborazione che analizza la forma d'onda acquisita e decodifica il protocollo in una forma leggibile dall'uomo. Tipicamente, i dati decodificati sono disponibili come sovrapposizione sulla forma d'onda o come tabella (alcuni oscilloscopi, come i modelli R&S RTE, RTO6 e RTP offrono anche strumenti di analisi aggiuntivi come l'utilizzo dei bus). Gli oscilloscopi con memoria profonda possono catturare lunghi periodi e poi effettuare ricerche per trovare gli eventi di interesse (o la frequenza con cui tali eventi si verificano). Questa tecnica è principalmente un approccio "software".

Il trigger, tuttavia, avviene all'interno del sistema di trigger dell'oscilloscopio. Un trigger sul protocollo monitora continuamente il bus seriale per determinare quando si verificano eventi. Ad esempio, due trigger comuni sono un indirizzo I2C o una condizione di errore (NAK o errore di parità). Le opzioni di trigger sono generalmente limitate a poche transazioni specifiche del protocollo e possono anche essere limitate alle profondità di bit di indirizzo, dati o payload. Questa tecnica è principalmente un approccio "hardware".

A volte, gli oscilloscopi combinano le due tecniche: il sistema di trigger può "eseguire un auto-trigger" mentre il decodificatore di protocollo trova l'evento di interesse e lo posiziona al centro dello schermo. Se l'oscilloscopio "perde" alcuni eventi, controllare il manuale per determinare quali condizioni di trigger sono basate sull'"hardware" e quali sul "software".