I have an I2C multi-master capable CPU connected to a battery with a BQ20Z65 gas gauge, an LTC4100 charger controller, and a few slave-only devices such as an I/O Expander.
CPU (multi-master)
|
+-- BQ20Z65 gas gauge (multi-master)
|
+-- LTC4100 charger controller (slave only)
|
+-- I/O Expander (slave only)
Both the CPU and BQ20Z65 are bus-masters. The BQ20Z65 sends updates to the charger controller at regular intervals, and our CPU talks to the charger controller and an I/O Expander.
The CPU properly senses traffic on the I2C, and only takes control of the bus when the bus is idle.
Unfortunately, the BQ20Z65 gas gauge does not seem to recognize when the bus is busy, and occasionally interrupts other transactions from CPU to I/O Expander. In the scope capture below, the CPU starts a Write cycle to the I/O expander. But in the second byte, the BQ20Z65 starts driving a START bit. When the CPU drives the next low clock, the BQ20Z65 seems to notice, and immediately aborts the START bit. But why did the BQ20Z65 start transmitting in the first place? It should have sensed that the bus was busy, and waited for an idle condition.
The yellow and white traces show the whole transaction.
The blue and red traces show a zoom around the collision.
The green trace is a trigger signal driven by our CPU after it detects the missing ACK.
Using a series resistor on the SDA line to the BQ20Z65, I was able to prove that the BQ20Z65 is indeed the one initiating the colliding START bit.
The collisions seem most frequent at bit 6 (on any byte), but I'm not sure whether that is significant. I have seen collisions occur on other bits, but less frequently.
We are running 50kHz I2C clock (also tested at 100kHz). For testing purposes, we are pumping out a transaction from the CPU to an I/O Extender constantly, with about 400-500us between each transaction.
I read the following in the TI document "SMBus Made Simple":
---------
An SMBus Master can only start a packet if the SMBus has been idle for more than 50
microseconds. Once this requirement has been met, then the Master immediately “grabs” the bus
by sending a start bit. All TI FG’s function exactly like this and since they are hardware
controlled SMBus Engines, they easily detect idle.
---------
This seems to indicate that the BQ20Z65 should have sensed the busy bus, and not attempted to start a transaction.
I have checked the datasheet to make sure we are adhering to the various timing parameters and voltage levels, and didn't see anything amiss.
Can you confirm whether the BQ20Z65 does, in fact, monitor the I2C bus for 50us idle before transmitting?
If so, is there some condition that is preventing it from sensing our CPU's activity on the bus?