Did you ever see a blocked I2C bus?
No communication after reset?
There are many reasons for a micro controller to go through a reset condition. Watchdog triggering, user events and intentional reconfiguration are only some examples.
For systems which employ an I2C bus such reset of a micro controller may have rather unexpected side effects if other components continue to operate during the reset phase.
I2C slaves work as a state machine. After they have been addressed they keep receiving bytes until they see another start condition or a stop condition send by the I2C bus master.
But what if the I2C master goes through a reset right in the middle of transmitting or receiving a byte from the I2C bus slave?
The slave is not aware of the reset and since I2C doesn’t really define timeouts it may well wait for the next clock event to send or receive a bit, not listening to any start condition which is likely to occur after a reset as startup sequence.
In other words, the bus is stuck, your I2C bus is blocked.
One rather clumsy but easy to implement solution is to toggle the clock line multiple (16) times before doing any I2C operation after power-up of the micro controller i.e. after it has possibly gone through reset. This sequence can be followed by a stop condition.
In many cases this will advance the state machine of any blocked slave to a point where it accepts the next start condition again.
A safer but more complex solution is to power cycle all I2C devices after a reset condition.
The key point to keep in mind is that an I2C slave is not stateless and therefore may not function properly out of the box after reset or – equally common – a spike caused by EMC influence interpreted as clock signal.