Hi there,
I think that we have discovered a bug in the implementation of the I2C interface of the given device corrupting communication with other devices on the same bus.
In our application the DAC is on the same bus as a 4kBit EEPROM, occasionally (but reproduceable, depending on the data written) the DAC disturbs the I2C communication with the EEPROM.
There seem to be two cases:
- Case 1:
The address of the DAC (plus read bit) - 0x19 in our case - is the nineth byte in the data stream since the start condition, e. g.
StartCondition,0xA2,0x90,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x19,0xFF
In this case the AD5695 kicks in after the 0x19 and destroys the 0xFF byte. - Case 2:
The address of the DAC is anywhere in the first eight bytes of the data stream, at byte 8 and 10 the address is repeated, but with a shift of one and two bits to the left, e. g.
StartCondition,0xA2,0x90,0x19,0xFF,0xFF,0xFF,0xFF,0xFF,0x33,0xFE,0x67,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
In this case the AD5695 kicks in and sends an ACK at the bit 1 of the value 0x67 effectively changing this value to 0x65 or 0x64 (depending on the next transferred data byte by the AD5695).
In both cases the controller (an NXP 11C14) will detect an arbitration loss and stop the transmission after the corrupted byte without trying to send a stop condition.
When disconnecting the SDA line of the AD5695R the errors are no longer observed.
We have analyzed the bus regarding signal levels, setup/hold times, noise etc. without finding any deviations from the standard, and with a logic analyzer to get the full communication sequence.
As the results are reproducable by 100% we assume that there is a bug in the I2C implementation of the AD5695. It looks as if the state machine isn't deactivated after an address mismatch but still looking for matches. It looks as if some internal bitcounter produces an overrun which in combination with the still active state machine leads to the activation of the data transmission.
As a workaround we now transfer only small blocks of data, but we need some qualified statement if that really guarantees an error free commmunication.
For further analysis I have attached some Saleae logic analyzer traces (you need the latest version to view them). Please note that after triggering the bug our software times out (after 20ms from the start condition), then issues a single byte write to recover the I2C and then waits a bit before triggering the bug with the next test pattern. The granularity of this timeout timer is 10ms, so there is a corresponding jitter in the idle times.
With best regards,
Torsten Lang
