I2C Protocol - How It Works, and What to Watch Out For
Engineers start young these days.  (Well, maybe not quite this young.)  One of the most common communication buses in the world, and hence one that should be well understood by prospective engineers, is the I2C bus.  It may not be as well known as USB or Ethernet, but much of our world of electronic devices is completely dependent on it.  It also has some siblings known as SMBus and TWI, which are essentially identical from a protocol standpoint.

The I2C protocol requires only 2 signals: clock and data.  Clock is known as SCL or SCK (for Serial Clock), while data is known as SDA (for Serial Data).  What makes I2C unique is the use of special combinations of signal conditions and changes.  Fundamentally, there are just two: Start and Stop.  There are some other conditions which derive from the presence or absence of these two, but they are the core of what makes this bus unique.

An I2C bus can potentially have multiple masters and many 'slave' devices sharing the same bus, although you rarely see multiple masters in the real world.  Signal contention is avoided by means of an open-collector drive scheme, where no device will ever drive a signal high, it only drives low; for a high, the bus is pulled up by a resistor.  An addressing scheme allows a device to determine if it is being queried by the master.  A master sees that a slave device is present when the slave responds to its address by sending an Acknowledgement bit (driving SDA low); if no such addressed device exists, the SDA line is pulled high, and this is interpreted by the Master as a Not-Acknowledgement. 

An IDLE bus condition is defined as having both SDA and SCL high.  (This condition can exist within a bus transaction, but generally it is transitory.)  A 'START" condition is generated by the Master, followed by 7 bits of address, then a ReadWrite bit.  If a slave device detects an address match, it will send an ACK by driving SDA low during the next clock cycle; if no slave recognizes the address then the SDA line will be left alone to be pulled up high.  Following a successful ACK, data will be either sent to the slave device or read from the slave device (depending on what was indicated by the Read/Write bit).  Therefore, each byte is 9 bits: either 7 address plus one R/W plus one ACK/NAK, or 8 data plus one ACK/NAK.  The last data byte of a transaction should generally be followed by a NAK, to indicate that it is intended to be the final byte.  After this, either a STOP or a ReSTART should be issued by the Master.

There are several places where bus errors can be introduced.  For example, data could follow a NAK of an address; this should ideally never happen.  It is possible that clocking could begin from a Bus-Idle condition without a proper START.  These are just a couple of examples.

Bus errors are rarely introduced when using a dedicated I2C peripheral on the Master, but are more common when creating the I2C protocol in a software-only solution (also known as bit-banging).  Identifying the source of these errors is extremely difficult to do by using an oscilloscope, even a digital scope.  The best solution is to use an I2C protocol analyzer.  One such product was recently released by Xtreme Engineering LLC, and it is available at www.easyi2c.com for just $99.  More information on its capabilities is available at that website.

All Site contents Copyright (C) 2010, 2011 Xtreme Engineering LLC