What is the I2C Protocol?
Engineers developing embedded systems have several options when it comes to selecting a communication protocol for their hardware device. One such option, the I2C communication protocol, offers unique advantages that make it an attractive choice for engineers.
The inter-integrated circuit or I2C communication protocol is a two-wire, clock synchronized protocol with a two-way data line and a one-way clock line. I2C protocol is fairly simple in the sense that it relies on just two lines of communication, but its complexity arises from the fact that all devices on the bus must communicate with each other using only these two lines. An I2C bus may have several master and slave devices connected on the same lines, and bus arbitration must be used to handle bus contentions and ensure that the correct data is driven on the bus.
I2C is asynchronous communication protocol, meaning that, like the SPI protocol, the output of bits is synchronized to the sampling of bits by a clock signal that is shared between the master and slave devices on the bus. In an I2C device, the master device always retains control of the clock signal.
I2C Protocol Testing Checklist for Embedded Systems
To successfully achieve communication on an I2C bus, a number of initial conditions have to be satisfied. The wiring on the device must be done correctly, the bus speed must be set to a speed that is usable by the master and slave devices, and the proper pull-up resistors must be present within the system. The master device must send the proper commands and the slave device should respond appropriately with an acknowledge (ACK) bit when the commands are received.
A useful starting point for debugging your I2C system is performing verification that each of the above requirements is being fulfilled. Here are the most important best practices to follow when debugging your I2C system.
Develop the Master First
Most guidance documents for I2C circuit design recommend that the user first develops the master device and tests it completely with a test slave before continuing development. Testing cannot be fully completed until the master and slave have been integrated, but delaying testing until this late stage can result in complicated errors that are difficult to resolve.
Instead, embedded engineers should test the master with a test slave that provides the necessary interfaces along with some additional test hooks. The implementing a test slave can be done with a microcontroller that could be used for slave development, or by using an independent host adapter capable of emulating an I2C slave.
Developing the Slave
Master and slave devices should be tested independently to ensure their stand-alone functionality before integration. Certain issues related to timing and signaling may only crop up once the final integration of the circuit has taken place, but the majority of functional testing can occur using an interface-driven test environment for separate validation of the master and slave devices.
Designing slave devices represents the majority of the effort throughout the design process, and the functioning of the slave should be the focus of the majority of testing efforts. Testing the slave device using an I2C master device, rather than the real master device that will be present in the system, is preferable. A purpose-built I2C master, such as the Total Phase Aardvark I2C/SPI Host Adapter or Promira Serial Platform makes it easy to send test transmissions to the slave device and verify that it is working properly prior to its final integration with the circuit.
Test and Validate Key I2C Features
You debugging efforts should ensure that the I2C circuit satisfies all of the requirements necessary for its normal functioning. You can start the testing process by verifying each of the following features on the I2C bus:
- START and STOP condition generation. A start condition is generated when the serial data (SDA) line switches from high voltage to low voltage before the serial clock (SCL) line switches from high to low. A stop condition is generated when the SDA line switches from low voltage to high voltage after the SCL line switches from low to high.
- ACK and NACK condition generation. Each frame in a message must be followed by an acknowledge (ACK) or no-acknowledge (NACK) bit that verifies whether the communication was successfully received. Your troubleshooting should include verification that ACK and NACK bits are transmitted when they are required.
- The response of the device under test in different states: idle, read, write, address_match, ACK.
- Synchronization of the clock between the master and slave. Timing issues still arise in I2C devices despite the use of a processor that generates a two-wired interface sequence. Sometimes the delay between the SCL and SDA lines is not compliant with the defined timing, which can result in unwanted START and STOP signals that occur in the middle of data transmission. Troubleshooting should verify that the bus is running at the right speed for the slowest slave device
- Validation of 7-bit address. Unlike the SPI protocol, I2C devices do not have slave select lines. The two-wire configuration used in I2C circuits means that all of the master and slave devices talk to each other on the same wire. Once a start condition is generated by the master device, it sends a 7-or-10-bit address frame that identifies the slave device on the bus that it wants to talk to. To coordinate data transfer between the many master and slave devices that may exist on the same circuit, each slave device is assigned a 7-bit or 10-bit identifying sequence called an address. Engineers should validate that each slave device on the circuit has been assigned a unique address and that all slave devices can be reached using the master devices on the circuit.
- The direction of data transfer by checking R/W bit. After the master device sends the address of the slave it wishes to communicate with, it sends a single bit that specifies whether it will be sending data to the slave device or requesting data from it. Sending data requires a low voltage level across the SDA line while receiving data would require a high voltage level.
- Generate all possible data transfer formats of connected devices.
Image by Like homes in a row, each slave device on the bus is assigned a unique address where it can be contacted by the master device to facilitate data transmission.
What Tools are Used for I2C Protocol Testing/Validation?
The 100kHz I2C communication protocol was first established by Philips Electronics in 1982, with a 400kHz fast-mode added a decade later in 1992. As such, there are many tools available for developers that can assist with programming and debugging or troubleshooting I2C systems.
The Total Phase Aardvark I2C/SPI Host Adapter can act as an I2C master or slave device with up to 800 kHz. It allows a developer or embedded systems engineer to interface a Windows, Linux, or Mac OS X computer via USB to an embedded system environment and to transfer serial messages using either the I2C or SPI protocol.
For developers working with I2C Fast Mode Plus at 1 MHz or higher, should consider the Promira Serial Platform by Total Phase. In addition to supporting speeds up to 3.4 MHz as a master or slave for I2C, it also supports low power devices down to 0.9V.
If you are developing your own I2C product, the Total Phase Beagle I2C/SPI Protocol Analyzer is an easy-to-use diagnostic and troubleshooting tool that can monitor activity on the I2C bus up to 4 MHz. With its accompanying Data Center Software, the Beagle I2C/SPI analyzer allows embedded engineers to monitor the serial bus and analyze data transfer across the bus using the I2C communication protocol in real time. Protocol analyzers allow engineers to directly examine the behavior of the I2C master and slave devices on the bus by capturing and analyzing data directly from the bus.
If you any questions about our Total Phase products, feel free to email us at sales@totalphase.com. You can also request a demo that is specific for your application.