Version 4.0 of the Inter-IC (I2C) bus is widely used in embedded system designs, and has been used for communications and control applications in thousands of integrated circuits.
What’s also still widely used is manual measurement and debug, in part because engineers assume that since I2 C has been around for a long time, there’s little to go wrong. The trouble comes when there’s a need to trigger bus commands using manual decode.
I2 , I2 C, or “I squared C”, stands for Inter-Integrated Circuit. It was originally developed by Philips Semiconductor in the early 1980s to provide a low-cost way of connecting controllers to peripheral chips, and has since evolved into a worldwide standard for communication between devices in embedded systems.
The simple two-wire design has found its way into an extensive cross section of chips including I/O, A/Ds, D/As, temperature sensors, microcontrollers and microprocessors from numerous leading chipmakers including Analog Devices, Atmel, Cyprus, Freescale, Infineon, Intel, Maxim, Microchip, NXP, Silicon Labs, ST Microelectronics, Texas Instruments, Xicor, and many others.
I2 ’s physical two-wire interface (Figure 1 ) consists of bi-directional serial clock (SCL) and data (SDA) lines. I2 C supports multiple masters and slaves on the bus, but only one master may be active at a time. Any I2 device can be attached to the bus allowing any master device to exchange information with a slave device. Each device is recognized by a unique address. A device can operate as either a transmitter or a receiver.
Click on image to enlarge.
Initially, I2 only used 7-bit addresses, but evolved to allow 10-bit addressing as well. Now four bit rates are supported: 100 kb/s (standard mode), 400 kb/s (fast mode), and 3.4 Mb/s (high-speed mode) and 5 Mb/s (ultra-fast mode). The maximum number of devices is determined by a maximum capacitance of 400 pF or roughly 20-30 devices.
Released in February 2012, version 4.0 of the I2 specification adds the 5 Mb/s mode for new serial data and clock lines using push-pull logic and adds an assigned manufacturer identification table. The I2 standard specifies the following format for messages:
* Start – indicates the master device is taking control of the bus and that a message will follow.
* Address – a 7 or 10 bit number representing the address of the device that will either be read from or written to.
* R/W Bit – one bit indicating if the data will be read from or written to the slave device.
* Ack – one bit from the slave device acknowledging the master’s actions. Usually each address and data byte has an acknowledge, but not always.
* Data – an integer number of bytes read from or written to the device.
* Stop – indicates the message is complete and the master has released the bus.
Since I2 uses separate clock and data lines, it is possible to use the clock as a reference point and manually decode the data line. However, the engineer needs to find the start of the message (data going low while the clock is high), manually inspect and write down the data value on every rising edge of the clock, and then organize the bits into the message structure.
Using a quick reference guide like that shown in Figure 2 , it can easily take a couple of minutes of work just to decode a single message and in a long acquisition and there’s no way of knowing if it’s the message you’re looking for until you’ve decoded it. If it’s not, then you need to start the tedious and error prone decoding process over again until you find the right message.
It would be nice to just trigger on the correct message content, however the state and pattern triggers traditionally used for years on scopes and logic analyzers won’t do you any good here. They are designed to look at a pattern occurring at the same time across multiple channels. To work on a serial bus, their trigger engines would need to be tens to hundreds of states deep (one state per bit).
Click on image to enlarge.
Fortunately, there is a better way. With the appropriate serial triggering and analysis application module, a mixed signal oscilloscope becomes a powerful tool for embedded system designers working with I2 buses. A typical mixed signal oscilloscope includes 4 analog channels and up to 16 digital channels, all fully time correlated.
By defining which channels clock and data are on, along with the thresholds used to determine logic ones and zeroes, you can quickly enable an MSO to understand the protocol being transmitted across the bus.
With this knowledge, the oscilloscope can trigger on any specified message-level information and then decode the resulting acquisition into meaningful, easily interpreted results. Gone are the days of edge triggering, hoping the oscilloscope acquired the event of interest, and then manually decoding message after message while looking for the problem.
As an example, consider the embedded system in Figure 3 . An I2 bus is connected to multiple devices including a CPU, an EEPROM, a fan speed controller, a digital to analog converter (DAC), and a couple of temperature sensors.
Clickon image to enlarge.
Now assume that one of these products was returned to engineering for failure analysis as the product was consistently getting too hot and shutting itself off. The first thing to check is the fan controller and the fans themselves, but they both appear to be working correctly.
The next thing to check for is a faulty temperature sensor. The fan speed controller polls the two temperature sensors (located in different areas of the instrument) periodically and adjusts the fan speed to regulate internal temperature.
One possibility is that one or both of these temperature sensors are not reading correctly. To see the interaction between the sensors and the fan speed controller, the first step is to connect to the I2 clock and data lines, and specify the input channels and voltage levels on the oscilloscope.
In this example, the two sensors are addresses 18 and 19 on the I2 bus, so the first move is to set up a trigger event to look for a write to address 18 (the fan speed controller polling the sensor for the current temperature). The triggered acquisition is shown in the screenshot Figure 4 .
Clickon image to enlarge.
In this case, channel 1 (yellow) is connected to SCLK and channel 2 (cyan) to SDA. The purple waveform The trace at the bottom of the display shows the decoded I2 bus. The upper portion of the display shows the entire acquisition. In this case, the oscilloscope captured a lot of bus idle time with a burst of activity in the middle. The lower, larger portion of the display shows this section zoomed in. The oscilloscope has decoded the content of each message going across the bus.
Taking a look at the acquired waveforms, the oscilloscope did trigger on a write to address 18 (shown in the lower left of the display). In fact, the fan speed controller attempted to write to address 18 twice, but in both cases it did not receive an acknowledge after attempting to write to the temperature sensor. (The oscilloscope indicates the no-acknowledge conditions with an exclamation point bordered in red.) The controller then checked the temperature sensor at address 19 and received back the desired information.
So, why isn’t the first temperature sensor responding to the fan controller?
Taking a look at the part on the board it turns out that one of the address lines was not soldered correctly. The temperature sensor was not able to communicate on the bus and the unit was overheating as a result. This example showed how a mixed signal oscilloscope can be used to quickly isolate a potentially elusive problem using I2 trigger and bus decoding capability.
In the example in Figure 4, the system was configured to trigger on a specific address, but it is also useful to trigger on a number of other conditions when working with I2 buses. Here are some useful triggering alternatives that are available:
* Start – triggers when SDA goes low while SCL is high.
* Repeated Start – triggers when a start condition occurs without a previous stop condition. This is usually when a master sends multiple messages without releasing the bus.
* Stop – triggers when SDA goes high while SCL is high.
* Missing Ack – slaves are often configured to transmit an acknowledge after each byte of address and data. The oscilloscope can trigger on cases where the slave does not generate the acknowledge bit.
* Address – triggers on a user specified address (as in the example above) or any of the pre-programmed special addresses including General Call, Start Byte, HS-mode, EEPROM, or CBUS. Addressing can be either 7 or 10 bits and is entered in binary or hex. Read or write may also be specified.
* Data – triggers on up to 12 bytes of user specified data values entered in either binary or hex.
* Address and Data – this allows the user to enter both address and data values as well as read vs. write to capture the exact event of interest.
These triggers allow you to isolate specific bus traffic, while the decoding capability makes it possible to see the content of every message transmitted over the bus in an acquisition.
The I2 serial bus is widely used, especially in systems that deal with sensors or human interfaces where simplicity and cost are more important than speed. Traditional manual decoding methods still in use to decode I2 on oscilloscope are time-consuming and inefficient. However, with the appropriate application modules installed, mixed signal oscilloscopes can trigger, decode and search I2 bus traffic, greatly improving productivity.
Dave Pereles, a staff engineer at Tektronix, has worked in the test and measurement industry in various roles including applications engineering and product management for over 25 years. Has a BS in electrical engineering from Trinity College, Hartford, CT and an MBA from Seattle University.