I2C Protocol Subtleties, Part 4: Unexpected STOP

This is the 4th in a series of articles on the more subtle aspects of the I2C protocol (which cover TWI and SMBus implementations as well). In the previous article, we discussed why there’s really no such thing as a ‘missing’ STOP on the I2C bus. Now it’s time to look at the potential issues around STOP, namely an “Unexpected” STOP as well as some bus errors around STOP. This deeper understanding of all potential bus errors can aid the engineer to craft a more robust system that tolerates and even recovers from these errors.

STOP is used to end a single- or multi-byte transfer, and relinquish control of the bus in a multi-master configuration. A Repeated START can accomplish roughly the same thing, but without relinquishing control in a multi-master environment.

STOP is always generated by the Master, never by the Slave. Since generating a STOP requires the Master to have control over both SCL and SDA, it is not guaranteed that it can do so at any time whatsoever. If the Slave is currently transmitting a ‘0’ data bit, the Master cannot issue a STOP. Of course, since the Master controls SCL, even in a software-based implementation it could theoretically monitor every data bit in a Slave-transmitted byte and issue a STOP at any time a Slave is sending a ‘1’.

Rather than showing up in the middle of a data byte, it is more likely that an implementation error would result in a STOP occurring at other specific points in the bus state flow. The following paragraphs detail these state flow patterns.

STOP after ACK:

In normal operation, a STOP will follow a NAK, whereas if an ACK is received the Transmitter will continue the operation with additional byte transfers. Therefore, receiving a STOP after a valid ACK can be termed ‘unexpected’, but might not be classified as an error per-se.

STOP without a preceding ACK/NAK:

In this case, the ACK/NAK bit is not seen at all, as the STOP is being issued prematurely. This is clearly a bus error, as the ACK/NAK bit is intended to be sent for every byte, under all conditions. However, it is more likely to be reported by a protocol analyzer as a ‘missing ACK bit’ than as an unexpected STOP bit.

STOP initiated from a bus idle condition (no preceding START or data or ACK):

It is possible to generate a STOP from an Idle bus state, by initially dropping SCL (thereby avoiding a START), then dropping SDA, then raising SCL, and finally raising SDA. Although a START was not present, a given Slave implementation might react in unexpected ways to the sudden appearance of what appears to be mid-byte clocking of the SCL line, and potentially a misbehaving slave device might try to output a Low on SDA once SCL has gone low. This condition is clearly also a bus error. A protocol analyzer would likely first report an unexpected Clock or data bit, followed by the unexpected STOP.

Again, it is theoretically possible for a Master to initiate a STOP even in the middle of a data byte, although this would not be viewed as ‘normal’.

During multi-master arbitration, it should be noted that it is not legal, per the I2C bus specification, to issue a STOP from one Master at a point where a data bit is being sent.

Finally, it should be noted that using the 10-bit addressing mode, versus the 7-bit mode, imputes no difference in the behavior or operation of the STOP condition.

As a special caution, all Master and/or Slave software-based implementations should be capable of recognizing a STOP (or a START for that matter) at any point in a bus transaction and reacting correctly, in order to prevent cascading errors. A STOP should force all devices to relinquish the bus and reset their internal states to the Idle condition.

This completes the discussion of STOP. Next, we’ll delve into the wonderful world of Repeated START. This topic didn’t receive a lot of direct attention in the I2C bus specification, so the discussion is certainly warranted. Thanks for reading!

(Copyright 2011 Robert G. Fries)