I2C Protocol Subtleties, Part 3: Missing STOP

This is the 3rd 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 some issues around the START condition; in this article we focus on a portion of what can go wrong with STOP.

What is a “normal” STOP?

Per the I2C specification, STOP is defined as a rising SDA line while SCL is high. Just like with START, this could theoretically occur at any point during a transmission (as long as a Slave is not currently driving SDA low), and should reset all I2C Slave devices (and Masters as well, in multi-master environments) back to an Idle state. Of course, having this occur under circumstances other than having just completed an ACK/NAK bit is an error (Unexpected STOP).

What is a “missing” STOP?

A STOP would be deemed ‘missing’ when an ACK/NAK is sent, followed by the bus returning to an IDLE state, and then a START (as opposed to a Restart) occurs. But, can this actually ever happen?

The ACK bit is sent by the ‘receiver’ of the preceding byte. At the end of the ACK period, indicated by the falling edge of SCL, the ACK sender must release SDA if the Master is to be granted full control of the bus. However, the Master is not always given *full* control over choosing the next operation. One of three operations could occur next: STOP, ReSTART, or sending a data byte (which could be either the Master being the ‘transmitter’, or the Slave being such).

In the case of a Slave Receive operation, the Slave has generated the ACK bit. If the ACK bit was low, the Slave is required to release the SDA line low after SCL falls at the end of the ACK period. Since the Slave asserted ACK, it is allowing the Master to send additional data bytes, or to send a ReSTART or STOP, as it chooses. If the Slave sent a NAK, it is indicating that it is unable to accept additional data bytes, and therefore would not try to hold SDA low for any reason. So, in the case of a Slave Receive operation, the Master is in full control of the bus after every ACK.

In the case of a Slave Transmit operation, the Master has generated the ACK bit. After SCL is driven low at the end of ACK, the Slave may wish to transmit an additional data byte, and will assume the role of ‘transmitter’ again, potentially driving SDA low in setting up the first data bit of the next byte. In this case, the Master does not have control over the SDA line. The only thing the Master can do, therefore, is release SCL, which is part of clocking in the first data bit. Therefore, by issuing an ACK (as opposed to a NAK), the Master is giving up its ability to generate a STOP or ReSTART after the ACK bit. If the Master generates a NAK instead, the Slave must cease its ‘transmitter’ role and not drive SCL after the NAK is seen. This allows the Master to control SCL to either generate a ReSTART or a STOP.

So, getting back to the question at hand, can there be such a thing as a ‘missing STOP’? The answer is, No. STOP is optional, since a ReSTART could be issued instead of a STOP. STOP would be required in order to release control in a multi-master configuration, but it is not possible, through bus observation, to determine whether a given Master *intended* to relinquish control but did not do so. In such a case, the bus would appear to be IDLE (both SCL and SDA high), but if no STOP were issued, the system would actually be awaiting a ReSTART or an additional data byte, involving the same Master.

In the case of a Slave Receive, if the Slave issued a NAK, it is expecting a STOP or ReSTART to be the next bus action. If instead the Master transmits an additional data byte, this error could potentially be classified either as indicating a Missing STOP, or as Unexpected Data. The best choice of classification is as Unexpected Data. The reasoning behind this decision is as follows: classifying it as a ‘Missing’ STOP implies that, although the STOP was omitted, subsequent bus states have returned to normal, specifically that a START or ReSTART, followed by a Master Address, would be seen prior to any data. Since a START or even a ReSTART are lacking in this case, the subsequent byte cannot be a Master Address, and must therefore be data. The bus sequence must therefore be viewed as a (mistaken) continuation of a data transfer. Indeed, it is likely that at some point soon, a STOP will in fact be issued.

The next article in the series will focus on another aspect of STOP, specifically the cases around an Unexpected STOP. Thanks for reading!