AnsweredAssumed Answered

AD9889B I2C controller silicon bug

Question asked by FredR on Apr 14, 2016
Latest reply on Apr 22, 2016 by rpdm


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.


Best regards,