Hi,
it seems that the bq20z95 in my system generates a START condition in the middle of a transfer conducted by another master.
In this example, my i.MX6 CPU tries to address slave device 0xD0 register 0x11. Slave device is a DS3231 RTC chip.
IImage may be NSFW.
Clik here to view.
I get ACK on the slave address, but NACK on the register address. The problem is at the arrow; a closer look:
Image may be NSFW.
Clik here to view.
In the 4th bit of the register address, the battery (bq20z95) kicks in and generates a START the moment where SCL and SDA are both high. You can see from the "low" level that the START is generated by another master that the CPU, and the bq20z95 is the only candidate (and the problem goes away if I remove the battery from the system). It seems to drop he bus immediately, but the erroneous START causes the DS3231 to NACK the transfer.
How and why can this happen? I2C masters are supposed to track the bus IDLE/BUSY state by monitoring START and STOP conditions continuously.
Actually, the bq20z95 data sheet states that t(timeout) is 25 - 35 microseconds! (SMBUS timing characteristics, page 9). I assume this is a typo; the SMBus spec. says 25 - 35 milliseconds. If it's microseconds, it could account for the observed behavior. But I doubt the chip was designed a factor 1000 off the SMBus spec?
Any idea regarding how to avoid this problem will be highly appreciated.
Thanks - Henrik
