Embedded system controllers use a host of serial data buses to communicate with other devices and sensors. Troubleshooting these buses has always been problematic. Going from an oscilloscope trace to a decoded message can be a cruel experience. Many designers resort to ‘bit counting’ in order to see the content of a serial data stream (Figure 1).
Whether the serial interface is the serial peripheral interface (SPI) or inter-integrated circuit (I2C) interface the process is the same (Figure 2).
I2C and SPI have a short physical range and are used mostly to transfer data to and from a microcontroller and local peripherals or sensors. The serial peripheral interface is a simple synchronous interface that uses hardware addressing and operates at clock rate of up to 50 megahertz (MHz). I2C is a synchronous master/slave communication protocol that supports multiple masters. It is also referred to as the two-wire interface or TWI.
The SPI is a basic interface for rapid data transfer without the programming overhead of a more sophisticated interface bus. Its master-slave topology uses a single master and can handle multiple slave devices using full duplex communications. The master device, usually a controller, uses a chip select (CSn) to address each slave. The bus contains a clock (SCK) and two data buses, master out slave in (MOSI) and master in slave out (MISO) for bidirectional data transfer. It only transmits data packets, making it ideal for transferring long data streams.
The I2C serial interface uses two bidirectional lines, clock (SCL) and data (SDA), for signaling at data rates up to 3.4 Mbps. It has a fixed data structure. Each I2C packet uses a unique 7- or 10-bit address. The transmitting device initiates transfers using a start bit. This is followed by the address of the destination device. A read/write bit indicates the direction of the transfer. The addressed device confirms receipt using an acknowledge bit (ACK). Multiple data segments follow with the direction determined by the read/write bit. Transmission stops with the assertion of the stop bit.
Testing and troubleshooting these interfaces, without resorting to bit counting, is simplified by using oscilloscopes equipped with serial data triggering and decoding software that allows simultaneous viewing of both the interface waveforms and the decoded data content while triggering on significant bus events. Oscilloscope software of this type is offered by all the major oscilloscope suppliers and is summarized in Table 1.
Supplier |
Option Model |
Interfaces Supported |
Max Clock Rate |
Decode Formats |
Simultaneous decodes |
Keysight |
DSOXnEMBD |
I2C, SPI |
I2C- 3.4 Mbps SPI- 25 Mbps |
Hex |
2 |
Rohde &Schwarz |
R&S Rxx-K1 |
I2C, SPI |
I2C- 3.4 Mbps SPI- 50 Mbps |
Binary, Octal, Decimal, Hex, ASCII |
4 |
Tektronix |
DPOnEMBD |
I2C, SPI |
I2C- 10 Mbps SPI- 50 Mbps |
Binary, Hex, Decimal |
1 |
Teledyne LeCroy |
EMBD TD EMBD TDME |
I2C, SPI, UART |
I2C- 3.4 Mbps SPI- 25 Mbps |
Binary, Hex, ASCII |
4 |
Table 1: Summary table of low-speed serial trigger and decode software options from key oscilloscope suppliers.
An example of a typical analysis of an I2C interface using a Teledyne LeCroy oscilloscope equipped with a low-speed serial data trigger decode measure and eye diagram software (EMBD TDME) option.
In a typical analysis, seven I2C packets were acquired and shown in the top trace. Below them is the clock signal. The third trace down is an expanded or zoom view of one of the packets. Each field within the packet is identified with a colored overlay and the data content of that field is overwritten within the overlay. A summary table, below the traces, lists all the acquired packets and their address and data fields along with their time of occurrence.
Other oscilloscope manufacturers offer similar functionality, enabling designers to avoid bit counting and focus on testing.