This is the second in a series of articles on the more subtle aspects of the I2C protocol (which also covers TWI and SMBus implementations). In the previous article, we discussed the basic hardware and software approaches to implementing support for I2C, as a master or slave. This article will discuss the Missing Start error condition.

What is a “normal” START?

According to the I2C specification, START is defined as a descending SDA line while SCL remains high. In theory this could happen at any point during a transmission and you should reset all I2C slave devices (and also masters, in multi-master environments) so that they are ready to accept a slave address transmission. Of course, this occurring under circumstances other than an idle bus condition or while waiting for a STOP is probably an error (unexpected START); this will be discussed in a later article.

What is a “missing” START?

A Missing Start condition could occur if the current state of the bus allows a START or a REPEAT START as the next state, but instead you see a falling SCL (with SDA high or low, but would generally be high). The above conditions would include: (a) Bus idle, followed by a START; (b) a NAK sent by a slave device after a read operation, followed by a repeat start, or (c) a NAK sent by the master after a write operation, followed by a repeat start. In the event that an ACK has been sent by the Master or a Slave, it is not possible to detect a ‘missing’ START as a repeated START or START is not necessary in these circumstances.

By definition, an idle bus condition can only be reached after a STOP is issued (although an idle condition can generally be assumed at startup after the master is initialized). During the idle bus, SDA and SCL are set high. Generating a missing start error in this case requires the SCL to drop while the SDA remains high. You might ask the question: Is it possible to retrieve valid data even in this scenario? In I2C, a falling SCL indicates that the transmitter (either master or slave) can now advance to the next data bit and update the SDA line. However, there were no previous valid data bits. Slave devices should be expected to ignore SCL activity until a valid HOME is seen, as the slave must not accept a slave address without a valid HOME preceding it.

After a NAK condition, the next bus state should be a repeated STOP or START. If activity is observed in SCL after a NAK, it can be assumed that a repeated START is missing, since a STOP was not issued (and therefore the bus remains under the control of the current Master). Slave devices will probably not treat the first byte following the NAK as a slave address, since a START or repeated START is required to prepare the slave device to accept a new address. The question of how the currently active slave responds to further synchronization after a NAK is device dependent, but any data presented should generally be considered invalid.

The next article in the series will focus on the missed stop error. Thank you for reading!