Hi,
We developed an audio device with digital AES/EBU interfaces implemented with two SRC4392. The control interfaces of the SR4392 are connected to a DaVinci (DM816x) processor via I²C. After the initialization phase the receiver status byte (register 0x13) of one of these devices is read out periodically (ten times per second). That's in principle not a problem. But on several PCBs the processor recognizes an arbitration lost on the I²C bus (see en.wikipedia.org/.../I²C. After a lot of tests we were able to verify that the SRC4392 itself is responsible for this failure.
For a better understanding I attached a screenshot from the scope. To identify the “faulty” device we put a 100 Ohm resistor in each I²C data line.
* Channel 1 (yellow): trigger signal out of the I²C Linux driver, drives low when an arbitration lost occurs
* Channel 2 (green): SCL
* Channel 3 (orange): SDA directly on the SRC4392 pin (after the 100 Ohm resistor)
* Channel 4 (blue): SDA on the PCB (before the 100 Ohm resistor)
As we can see the master writes the slave address 0x71 for the SRC4392 on the bus followed by the register address 0x13. The next transfer should be a repeated start to read out the status register. But the transfer stops because the SRC4392 pulls the last bit of the register address to low without permission (see mark “faulty 0”). Channel 3 (orange) has a voltage level of about 0V instead of Channel 4 (blue) that is about 100mV. And this is a clearly proof that the SRC4392 pulls down the line.
The next picture shows a more detailed screenshot of the same signal. The clock frequency of the I²C is 100kHz, timing and levels are all within the specification. We configured the sampling bandwidth for Channel 3 and 4 on the scope to 500MHz. As well on the I²C lines as on the power supply pins (not shown here) are no disturbances like noise or glitches visible.
The arbitration lost occurs non predictable. So the time to the event is something between one and several hours. We have some other screenshots where the fourth bit of the data 0x13 is pulled low. So it looks like the SRC4392 miscounts the clock pulses.
We replaced the affected chips on a few boards with the result that these boards never had this failure again within the last weeks.
Currently we don’t believe in a defective charge of the SRC4392. But we do need some help with this issue very urgent.
Thanks for any response.
