Validating and using the I2C protocol

Vera Apoorvaa, Cypress
EDN (July 15, 2014)

I2C is a two wire, clock synchronized 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.

To read the full article, click here