App note: Implementing an I2C reset

an_ad_an686

Interesting app note from Analog Devices when an I2C communication is broken under some circumstances. Link here (PDF)

The I2C bus is a high integrity, robust serial bus used for control purposes in many systems. The primary components that make up a system are at least one master and one slave. Under normal conditions, everything works fine; however, it is the abnormal conditions that generate problems. Two questions present themselves when a problem arises: Is the problem device or system related, or some combination of both? What, if anything, can be done about it?

Hard device failures are relatively easy to isolate. Perhaps a function does not work, proper power cycling does not resolve the issue, pins are stuck high or low, and so on. System related problems sometimes disguise themselves as device failures, or worse, are intermittent. It is the latter area that this application note examines because it represents the majority of bus fault conditions.

Frequently the master, which is usually a microcontroller or a gate array, will be interrupted in the middle of its communication with an I2C slave and, upon return, find a stuck bus. Initially this looks like a device problem, but it is not. The slave is still waiting to send the remainder of the data requested by the master. The problem is that the master has forgotten where it was when it was interrupted or reset.

Join the Conversation

3 Comments

  1. Ran into this last week. One additional note: SMBus specifies yjat pulling CLK low for 35 ms will cause the slave to reaset its interface to the idle state. However, I was not able to get this to work with my chips even though they claimed I2C and SMBus compatibility.

  2. The “9 clocks” trick is widely used IME. The app note blames the slave but it’s usually something like a watchdog reset causing the master to abort that gets the bus stuck and then it doesn’t come back after a reset. These clocks at reset and then if bus ever sticks afterwards gets everything reliable.

  3. I had this problem on a product I was developing; easy enough to fix; I just switched the pin mux for SCL back to a GPIO and clock it a few times (e.g. 8-16 times should do it) by manually wiggling it; this is enough to cause any device that got stuck halfway through transmitting to clock out the remaining bits and release the bus

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.