A modern scope can take the tedium out of checking protocol operations in an embedded system with multiple I2C devices
In designing and testing an embedded system, engineers need to provide a way for the various devices and subsystems on the system, such as DACs, low-speed ADCs, fan control chips, EEPROMs, and PLDs to communicate. The Inter-Integrated Circuit protocol, more commonly known as I2C, is one of the more popular protocols in use today.
Unlike protocols such as SPI and UART that may need multiple dedicated I/O connections, I2C communication takes place using only two I/O connections. Since I/O connections on embedded systems are generally scarce and engineers need to use a minimal number of pins per device, the I2C protocol is often preferred. However, when using an embedded system with multiple I2C devices, debugging the I2C protocol can be tedious. But by using a modern digital oscilloscope for debugging, engineers can analyze the I2C protocol and view physical signals without disrupting the system.
Understanding I2C
It is important for engineers to understand the protocol thoroughly in order to select the correct set of tools for debugging. I2C is a multimaster single-ended serial protocol, which means it can support multiple slaves and multiple masters on the same bus. It is based on two bidirectional lines, Serial Clock Line (SCL) and Serial Data Line (SDA), which are pulled high with pull-up resistors. These lines together are commonly known as an I2C bus, which is used for communication among all I2C devices (multiple masters and slaves).
I2C protocol comes in four modes: Standard mode (100 kHz), Fast mode (400 kHz), Fast mode-Plus (1 MHz), and High Speed mode (3.4 MHz). The protocol consists of a Start bit, Address bits, read/write (R/W) bit, data byte, acknowledge bit (ACK), no-acknowledge bit (NACK), stop bit, and re-start bit (which is equivalent to Start bit without a stop bit).
Fig. 1. The screenshot shows I2C address, and how SDA and SCL signals are interpreted for various protocol components.
The Start bit (S) is always sent by a master to initiate communication. It is defined as high to low transition on the SDA line, while SCL is held high.
Address bits are either in a 7- or 10-bit format, depending on system configuration. The 7-bit format has fixed address bits and hardware-selectable address bits (optional), for a total of 7 bits. And the 10-bit format consists of a fixed command (11110) and a 10-bit address (fixed or hardware selectable).
The read/write bit (R/W) is the eighth bit on the address byte, where low is write and high is read, for the 7-bit addressing mode.
In the 10-bit addressing mode, read/write is a little more involved than the 7-bit addressing mode. The write operation consists of two bytes, and the read operation consists of three bytes.
Fig. 2. The display shows Write (top) and Read (bottom) addressing for 10-bit I2C mode.
The data byte is sent by the transmitting device (master or slave) and the acknowledge bit (ACK) occurs on the ninth SCL clock pulse. It is transmitted by the receiving device, while it pulls SDA line low. The no-acknowledge bit is transmitted when the receiving device fails to pull the SDA line low. The transfer is aborted when NACK is received. The stop bit is always sent by the master to end the communication. It is defined as low to high transition on the SDA line while the SCL line is held high.
Debugging the I2C protocol
Embedded-system engineers must make sense of the I2C messages sent back and forth on their system. They must identify the messages being sent to a particular device based on the device’s address, and then continue to analyze the payload/data bytes transferred between the devices.
Often, engineers use low-cost I2C sniffer/analyzers to capture I2C traffic for analysis. However, most embedded designs have no connector to attach an I2C analyzer on the embedded board, so engineers must look at electrical signals on the I2C bus to make sense of the error or messages transferred among devices.
The problem becomes even more complicated when the device that must be debugged is hot swappable, and engineers cannot put the entire system in debug mode. Oscilloscopes are very useful in these situations, because they allow engineers to probe the I2C bus and capture I2C traffic without disrupting the entire system.
Nevertheless, capturing I2C traffic is only half the battle. Engineers must also decode the messages sent to several devices, and so often spend many hours manually counting bits. An oscilloscope with an I2C trigger and decode package avoids the frustration of decoding messages manually and gives an instant snapshot of the I2C communication taking place.
For example, consider the state of a Nintendo Wii controller’s I2C bus while it is connected to a FreeStyleGames DJ Hero system (see Fig. 3). Since the Wii controller and DJ Hero communicate over I2C, several packets are being sent back and forth at any given time [1].
Fig 3. I2C traffic with multiple devices.
Using a modern digital oscilloscope, engineers can capture I2C traffic and use its decoding capabilities to analyze messages communicated between the master and the slave. The scope’s ability to decode the I2C protocol lets engineers debug the design efficiently and effectively. To quickly view timing and packet relationships, a table view provides a higher-level snapshot of a long I2C bus capture.
The table view in Fig. 3 shows messages (in the data column) sent to each device based on the device address (in the address column) and presents the data in a format similar to a sniffer/analyzer. Also, the scope’s I2C trigger capabilities enable engineers to focus on the device they plan to debug, using specific address and data triggers to isolate communication between a particular slave and master.
Advanced debug tools
Finally, some oscilloscopes also have feature-finding algorithms that help engineers interpret what surrounds the anomaly and what caused it on the SCL line (see Ffig. 4). The feature finder is especially helpful in locating the clock synchronization process, which is automatically performed by masters in a multi-master environment.
Fig. 4. The runt is shown in the yellow box and the “found feature” in the lower trace. The upper left shows a table of three features found that met this condition.
The I2C protocol is ubiquitous in embedded systems, but the protocol structure of multiple slaves and masters creates many challenges to solving problems in a system. Choosing the correct scope with specialized trigger, decode, advanced search, and viewing tools can simplify and shorten the debug process. ■
- Note that no claims are made regarding any known bug in Nintendo Wii and FreeStyleGames DJ Hero. These systems were used merely to provide an example of a hypothetical real-world situation.
(source www2.electronicproducts.com- Vrajesh Dave of LeCroy, Chestnut Hill, NY http://www.lecroy.com)
Latest posts by Mike Novello (see all)
- Used Bio-Rad Gel Doc XR For Sale - March 9, 2022
- CONSULTIX WTX-35-A4 CW Test Kit For Sale - November 9, 2021
- Biologic SP-150 Single Channel Potentiostat and VMP3B-80 Booster For Sale - September 7, 2021
