I2C Protocol Analyzer - a Helpful tool, or overkill?

I2C - A Simple Protocol?

The I2C bus may appear to be simplistic on the surface.  After all, it has only two wires and 4 bus states: Start, Data, Ack, and Stop.  That simplicity is deceptive.

Some of the complications appear due to its other capabilities that don't directly correlate to the bus states, such as Multi-Master support and Arbitration, as well as clock stretching, bus timing nuances and open-drain connections, and even clock-stretching timeouts in SMBus.

Other complications arise due to errors caused by either the system environment (inadequate pullup strength, highly capacitive lines, conflicting Slave addresses), or by implementation errors on the part of the designer (improper bus state management by the Bus Master, errors in software-based implementations of either the Master or a Slave, or exceeding a Slave's bus speed limit, for example).

Many microcontrollers implement I2C in hardware, and this helps ensure correctness of implementation somewhat automatically.  However, problems can still arise.  As one example, consider an incorrect implementation of the Master Read function.  When intending to stop the read operation, the Master is supposed to issue a NAK after getting the final desired data byte, followed by the Master issuing a Stop or Restart.  If the Master issues an ACK instead, this could potentially disrupt other Slave devices that don't correctly handle that error (even though they work fine under correct bus sequences).  Arbitration problems in multi-master systems are also difficult to isolate.

Designers need a faster way to discover an correct these flaws. That's where a Protocol Analyzer can help.

Benefits of a Protocol Analyzer

In the past, protocol analyzers were expensive and complicated to use, thus limiting their availability to larger corporations.  That has now changed, with the arrival of some incredibly useful (and cheap!) new analyzers, such as the $99 (USD) EasyI2C(TM) from www.easyi2c.com.  Protocol Analyzers already understand the in-depth details of a given protocol, and can thus report both correct and incorrect behaviors with supporting explanations about what went wrong (or right).

Some analyzers show a waveform (not a true analog display, but rather a digital equivalent similar to what you would get from a logic analyzer) and subsequently expect you to decode the results in your head.  Waveform display, in our opinion, is of very little value in this form.  First, the value of the vaveform actually resides in its accurate representation of the analog nature of the signals, such as showing the rise and fall times of the signals, 
ringing, or bus contention.  Without that, the waveforms can actually mislead you in figuring out the issue, especially if the designer forgets that they are not a correct representation of the *analog* signals.  By comparison, a textual explanation of what has occurred cuts to the chase and can instantly, and without requiring deep knowledge of the subtleties of the bus on the part of the user, identify the root cause of a problem.

Textual results can also be used as part of the documentation of a completed project.  As such, they can provide a clear and concise self-documenting training manual for new engineers or repair personnel as to the expected (correct) bus behavior under various operational modes and circumstances.  Having a report showing an ideal bus sequence makes it much easier to diagnose errors if any problems arise in the future.

The Bottom Line

Debugging bus problems without a protocol analyzer is certainly possible, but with tools like the $99 EasyI2C(TM) being available, the question becomes "Why Bother?"  Tools make our life easier; that's what they are for.  Failing to use them is a waste of resources that can doom a project by causing unnecessary delays and frustration, giving competitors the chance to beat you to market at reduced cost.

(Copyright 2011 Robert Fries; All rights reserved worldwide.)