This is the 2nd 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 the basic hardware and software approaches to implementing support for I2C, as a Master or as a Slave. This article will discuss the Missing Start error condition.
What is a "normal" START?
Per the I2C specification, START is defined as a falling SDA line while SCL remains high. This could theoretically occur at any point during a transmission, and should reset all I2C Slave devices (and Masters as well, in multi-master environments) to be ready to accept a Slave Address transmission. Of course, having this occur under circumstances other than a Bus Idle condition or while awaiting a STOP is likely 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 bus state permits either a START or a REPEATED START as the next state, but instead sees a falling SCL (with SDA being either high or low, but generally it would be high). The preceding conditions would include: (a) Bus Idle, followed by a START; (b) a NAK having been sent by a Slave device after a Read operation, followed by a Repeated START, or (c) a NAK having been sent by the Master after a Write operation, followed by a Repeated START. In the case of an ACK having been sent by either the Master or a Slave, it is not possible to detect a 'missing' START since a START or Repeated START is not required under these circumstances.
By definition, a Bus Idle condition can only be arrived at after a STOP is issued (although at Startup an Idle condition may usually be assumed after the Master is initialized). During Bus Idle, SDA and SCL are defined as both being high. Generating a Missing Start error in this case requires SCL to fall while SDA remains high. The question could be asked, Is it possible to recover 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 was no previous valid data bit. Slave devices should be expected to ignore SCL activity until a valid START is seen, as the Slave should not accept a Slave Address without a valid START preceding it.
Following a NAK condition, the next bus state should be either a STOP or a Repeated START. If activity is seen on 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 likely will 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 additional clocking after a NAK is device-dependent, but any data presented should generally be viewed as invalid.
The next article in the series will focus on the Missing Stop error. Thanks for reading!
No comments:
Post a Comment