Fried I2C ports?

Products Support HiKey 960
#1

I think I might have exposed the I2C0 port on one of my 960’s to a shorted 5V line. When I monitor the clock line on a scope, using i2cdetect, I see that it just gets pulled down once to go back up to 1.8V, instead of showing 10 clocks like the other one (that was in a box) does. This goes hand in hand with a lot of:

[ 6.858949] i2c_designware ffd71000.i2c: i2c_dw_handle_tx_abort: lost arbitration

So I assume I fried it. The question is, how much damage have I done? Which parts of the board are damaged and could it be fixed?

#2

Its really hard to debug hardware remotely, but I can say that the pins on these boards have proven to be fairly resilient. For instance, there is a guy in this thread ( Connecting MCP2515 via SPI for CAN driver with Android kernel 4.9 - #10 by 7atech ) who hit his SPI pins with 5v, and it apparently survived. Note however that he seems to have only hit it with logic 5v, which would be current limited to whatever the logic port of the 5v device can drive it with, which is probably pretty low. If you hit it with the 5v power supply line, that could be very different.

I have seen the “lost arbitration” error message from the i2c bus on one of mine before. It happens when I plug in a GT911 touchscreen, which works for a little while, but eventually gives me that error. I have no idea what happens that triggers the error, all I know about it is that the i2c bus will be dead until the board is rebooted. Also note that the GT911 is on the 3.3v side of a level shifter, with another i2c device. The other i2c device alone doesn’t cause any trouble, and neither do the 4 1.8v devices.

I wonder if your scope might be interfering with it? Maybe try adding external pull-up resistor and see if that helps? I’d suggest starting with 4.7k.

#3

And one other thing to consider; I have seen a lot of reference to this particular error often being triggered by the i2c device being connected on a WIRE. The length of the wire, i.e., to your scope, or a device (if you have one connected), could be impacting it. i2c likes everything to be nice and close together on a PCB. It is, after all, “Inter-IC” and not “External-WiredStuff” (and yes, my GT911 is on a wire – the ONLY i2c device I have on a wire).

#4

In the test setup the only wires connected are two jumper wires that the scope is hooked up on. With another 960 it works fine. Why would additional pullups improve the signal to come down again? As it seems now, something is pullibg the lines high too strongly to be pulled down to make a clock signal.

Anyway I could test using a PCB mezzanine that does not have any wires, and has the right pullups.

#5

To some extent I can only really offer sympathy. Predicting (accurately) how the chip can break if electrically abused is pretty difficult.

Having said that you perhaps should watch the data line as well. To lose arbitration after a single clock cycle could come from the data line rather than the clock line. Losing arbitration usually means that the master has observed one of the lines pulled low when it should have floated high.

Naturally however if the pad might be damaged we don’t really have anyway to be sure that it will read the values from the lines correctly…