we have discovered a serious problem on one of our products that uses an AD9880 along with an AD9889B.
On some boards (3 identified so far), the AD9889B acknowledges one of its 3 slave addresses (0x70/0x71, 0x7A/0x7B, 0x7E/0x7F) in the middle of a configuration message sent to the AD9880 chip.
We can trigger the failure by writing the register 0x25 of the AD9880 :
START 0x98 ACK 0x25 ACK 0xF5 ACK STOP.
From time to time, the byte 0xF5 gets changed to 0xF4 by the AD9889B chip that inserts an acknowledge on bit #0.
1) Previous byte must have bit #0 set (this is the case with byte 0x25)
2) ACK from AD9880 is first interpreted as a START by the AD9889B (Why ? We do not know : SDA gets low 40ns after SCL. So, this is not a START condition). ACK bit is also interpreted as slave address bit #7 by the AD9889B.
3) 0xF5 left shifted is 0x7A : bits #7-1 are interpreted as slave address bits #6-0
4) Bit #0 of 0xF5 becomes the ACK bit for the AD9889B.
We have verified that the failing bytes values are :
1) 0xE1, 0xE2, 0xE3 => AD9889B "answering" to slave address 0x70/0x71.
2) 0xF5, 0xF6, 0xF7 => AD9889B "answering" to slave address 0x7A/0x7B.
3) 0xFD, 0xFE, 0xFF => AD9889B "answering" to slave address 0x7E/0x7F.
We have also verified that by writing 0xF0 into register 0xCF, case 1) disapears and by writing 0xFE into register 0x43, case 3) disapears.
This is a very serious issue, we have around 1000 devices in the field that are potentially affected by the bug.