Path: EDN Asia >> Design Centre >> Test & Measurement >> Validate, utilise the I2C protocol
Test & Measurement Share print

Validate, utilise the I2C protocol

29 Jul 2014  | Vera Apoorvaa

Share this page with your friends

I2C is a two wire, clock synchronised protocol with a bi-directional data line and a uni-directional clock line. Its simplicity lies in its use of only two lines for communication and its complexity lies in the fact that these lines are shared among all the devices on the bus. The I2C bus can have several masters and slaves connected on the same two lines and bus arbitration is employed to handle bus contentions. The scope of this article is to bring out some common I2C issues that come up while validating and using the I2C protocol.


Bus contention and arbitration: An overview
When a master sends data on the bus, it also repeatedly probes the bus to ensure the data it sent out is actually driven on the bus. When two masters drive data simultaneously on the bus (let us assume a simple case wherein both masters are operating at the same bit rate), all goes well until the data bits driven by both masters are the same. When the data bit they drive differ, that is, say master A drives a dominant bit (read '0' for an open drain drive low bus) and master B drives a recessive bit (read '1' for an open drain drive low bus), the resultant bus state is dominant ('0'). Master B senses it has lost arbitration and backs away from sending the rest of the message bits. Master A completes its transaction with no intervention. In fact, master A has no clue that master B has been contending for the bus (figure 1). In summary, all devices on the bus are capable of driving data on the bus and are listening to the bus. Hence, it is important that all devices function in compliance and misbehaving devices be identified and isolated.


Figure 1: Master A gains arbitration while master B loses arbitration.


I2C validation and debug
A qualitative validation strategy aims at determining what can go wrong on the I2C bus rather than what can go right. The foremost task is to understand the scenarios that can go wrong. The next step is to determine the expected behaviour of the device under test (DUT) and finally and most importantly, devise a method to generate these error conditions. After all, implementation feasibility determines testability. In the course of I2C validation, I have come across numerous issues and wish to share some of them further in this article.

Some typical device combinations on the I2C bus include:

 • Single slave and a single master
 • Multiple masters and a single slave
 • Single master and multiple slaves
 • Multiple slaves and multiple masters

Case 1 is quite simple and not many issues are expected for a fairly well designed master/slave device. Cases 2, 3, 4 involve more than one device sharing the bus and hence it is important that the devices are well designed not to misbehave as well as are capable of recovering from error scenarios.


Figure 2: I2C start condition.


Figure 3: SCL stuck low condition.


Figure 4: SCL and SDA stuck low condition.


Interpreting a bus stuck low scenario
The SDA/SCL line being stuck low (figures 3 and 4) is a communication impairing condition. When this happens, no master can generate a start condition (figure 2) and hence disabling any further communication. This in most cases requires reset of the device holding the bus low or master to send the bus clear sequence to recover the I2C bus.

1 • 2 Next Page Last Page


Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.


Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming


News | Products | Design Features | Regional Roundup | Tech Impact