I2C SDA remain low

[cosminnci]

Hello,

I have an i2c over 2 p82b715 bus extenders
it worked for 1 entire day then stopped.

I attached 2 screen caps from a logic analyzer, it seems I do not have a stop condition and the data line remains low.
after trying another command from the local board it generates 8 clocks and recovers.

what could cause this behavior?

thank you,
regards,
Cosmin

[Kjelt]

It's called a stuck I2C bus, cause: de-synchronisation in one of the ic's statemachine with the clock of the master.
Remedies in order:
- let the master do some extra clocks and hope the statemachine progresses and the ic is finished (should be 1 to max 8 clocks) so stop when SDA is low and continue normal operation keeping close eye on SDA (could be that the ic is still in wrong state).
- reset the ic that pulls down the SDA bus (try one after another till success)
- power reset the I2C ic's
- last resort power down the entire board.

Things to do to prevent it: check clock frequency and lower it a bit and see if it still gets stuck within a few days.

I had the same problem however the ic causing it had no reset, so powering down was the only remedy.
This is not good practice so I will probably replace it with a similar functionality ic with reset.

[Kjelt]

Here is some stuff to read.

[cosminnci]

Hello,

thank you for the reply,
I lowered the frequency from 100kHz to 50Khz and same bahavior.
I use a 30m cat5 cable with the bus extenders
and the logic analyzer was on the long cable.
yesterday it worked all day, and today it doesn`t even with lower speed.
the clock and data signals look ok as shape and amplitude.
I am using the default arduino library.

Is there a better library that has some recovery options or more optimized for long cables?

regards,
Cosmin

[Kjelt]

wow wait a minute 30 meters cable? I2C was intended for between IC's on a pcb not for long distance communication.
There are limits to capacitance on the bus and also the I2C in/outputs are not extremely robust against transients etc.
Maybe it is better if you switch to RS485 for your dataprotocol?

[cosminnci]

I am using p82b715 bus extenders which in theory can do that.
funny thing is yesterday worked all day and today it won`t, same hw same everything.

[lapm]

I use a 30m cat5 cable with the bus extenders

30 Meters in I2C bus? tahts way too long. I2C is inteded for in board use... If you really need something long like that go with rs-485.. Much more reliable...

[jlmoon]

How about removing the 30m cable and attaching the two devices as if on a single board (as per the I2C guidelines specify) do test.. get results, study them then work on your interface techniques.   

One other thing, what are your supply voltages on those parts.. .both ends.  According to datasheet specifications degrade if Vcc < 4.5V, and I hope you're employing pull up resistors (observing calculated net resistance/capacitances  to time constants) to make those open collector buses happy.

[free_electron]

yes you can run i2c over long distance. i've ran i2c through buildings without problems using those 8c715's.

carefully check the signal levels after the 715. you do have a 715 on both sides right ?

for anything over 10 meters you may want to up the pull up voltage. the 715 can handle up to 15 volts i believe. nxp has an appnote how to do the calculation of the resistors and voltage in terms of speed and cable capacitance.

[cosminnci]

I am using 715 on both sides, supply is 5.3v 2A switching and a 100uF electrolitic, It looks smooth
I have pullups of 560ohm on both sides and both lines.
I think the clock line looks weird, amplitude varies, I attached a capture.
I have 2 channels same setup one was working one wasn`t after 1 day.
on short distance it works flawless, but connected together when the long line gets stuck it blocks the local one.

[PioB]

Are you using DC coupling on the scope?

[cosminnci]

it is a dso nano, with standard probes, don`t think it has the feature.

[mikerj]

Looks like your clock rate is way too high for the amount of loading on the bus, since the clock isn't getting anywhere near the full drive level.

How are you generating the I2C, from an I2C peripheral in a micro, or bit-bashing it?  Suggest you check your timings!

[cosminnci]

I use an arduino to generate the I2C signal.
I increased the pullup not it looks better but still not sure how reliable it is.

[dannyf]

I increased the pullup

Depending on what you meant by "increase", that sentence can be weird.

Agree with others. Your clock rate is too high for what you have on the bus.

[cosminnci]

this might sound as a very dumb question,
is there a speed limit over which my communication over the i2c would start to fail?

I mean I have a pc making continuous requests to an arduino which passes them over i2c and over the buffered bus but it has no delays, it goes as much as it can write.
my i2c is working at around 100khz, and I have failure on the communication even sometimes the bus hangs.
would this be a valid explanation ?

[Mad ID]

Check if your sda/scl rise times are faster than 1us. That is a requirement from the specification

[Rerouter]

Looking over the AVR's I2C library, it has no timeout functions, so that is not likely the case, the next concern is that these chips have a 4nF capacitance limit,

how about you grab a multimeter with capacitance and see what you are actually getting,

also looking at figure 6 onwards in the datasheet details how to calculate the right size pullups for 100Khz operation while still being in spec, from that capacitance measurement.

http://www.nxp.com/documents/data_sheet/P82B715.pdf

[cosminnci]

It works properly about 20 cycles then  it crashes, I2C stop condition is not sent , SDA remains low and I have set the watchdog to reset the atmega, and it restarts.
attached are 2 cases, on bottom img it works on top it misses the stop condition.
I don`t really understand why it did not generate the stop condition.

[AndreasF]

I think the question is, why is there an extra falling SCL edge (followed by another rising edge) when the transfer works, but not if it doesn't. I think it's still waiting for the ACK/NACK from the slave (which might be detected on the falling edge?).

[cosminnci]

I use the default arduino library, and on small distance it works.
when I use the buffers I get the situation form the previous image.
I was thinking of some timing problems caused by the bufers with the long cable.
but on the analyzer I don`t see that.

[Rerouter]

This is the second time i will say it... Measure the cables capacitance, these chips have a maximum of 4nF, exceed that and everything starts going pear shaped.

[Howardlong]

I think the question is, why is there an extra falling SCL edge (followed by another rising edge) when the transfer works, but not if it doesn't. I think it's still waiting for the ACK/NACK from the slave (which might be detected on the falling edge?).

Looks like it's the master side not working. A scope rather than LA trace may help show whether it's a physical layer problem or in the software.

BTW, for I2C, rise and fall times are measured between 0.3Vdd and 0.7Vdd rather than the usual 10%/90%.

[cosminnci]

I have a ax-ms8250 dmm, it has capacitance meter on it but never used it .
so far I have:
regular UTP cable
pin 1 GND
pin 2 SDA
pin 3 GND
pin 4 VCC
pin 5 GND
pin 6 VCC
pin 7 GND
pin 8 SCL

I unplugged both ends, on one end placed a utp connector and measures.
between 2 twisted wires I have 1.4nF and between wires from different twisted pair I have 0.8nF

I use 560 ohm pullup on both sides at 5V


thank you.

regards,
Cosmin