I2C bus needs capacitance?

What's the rise/fall time of your signals like, when the master is driving them? Are your I2C lines terminated anywhere, or are they just traces/wires?

If your master is hitting the lines with really fast edges, and if you don't have termination resistors installed at appropriate ppints, it's possible that the slave devices are seeing some ringing on the bus, and are mis-clocking.

Thank you for your input, Dave.

The only terminations are the 10K pullups on all lines as shown in my schem atic. Early on I tried lowering them to 5K, no change. I didn't measure t he slew rates, but will when I get back to the shop in the morning. They l ooked 'fast' to me.

I wonder if I've inadvertently inverted my clock, so the added capacitance is slowing the data just enough that it is in the right state when the othe r (correct) clock edge arrives. Perhaps I got lucky with earlier boards ha ving more built-in capacitance? I don't know, that just feels unlikely at

Those 10K pullups are pretty wimpy. If the rising edges are slow, you could get clock/data skew. Try smaller resistors?

Weird. Check the low voltage on the 3.3V side -- I expect it'll be one diode drop, courtesy of the bulk diode in the FET. The low may be marginal for your 3.3V device.

NXP has level translators. I've only used them on one board, and it's still in the prototype stage, but I've had zero problems so far.

On Wednesday, October 5, 2016 at 4:58:29 PM UTC-7, Tim Wescott wrote: ...

... It shouldn't be. The FET is biased on since there is 3.3V on the gate and so should have negligible D-S voltage.

I've successfully used that circuit a few times with no problems. It has its limitations since there is only a passive pullup on the slave bus and yet the master has to provide the current for both pull-ups.

I would think the most likely problem is that the setup or hold time is being violated.

There are filters in the I2C slaves that should ignore ringing and other noise on the bus.

kevin

Most likely, or the clock is ragged.

Believe that if you want to but you're just asking for trouble if the clock isn't perfect. Not everyone follows the spec. I2C can be major aggravation even if everything looks right. Hint: Put 0-ohm series resistors on every node (0404 2 x R-packs are great, here). When things get ugly, at least it's easy to isolate devices.

Does the level at master come out correct if the slave clamps the clock?

it also has this:

and it works very well.

Bye Jack

On Thursday, October 6, 2016 at 12:37:22 AM UTC-7, Tauno Voipio wrote: ...

...

Yes, that circuit supports clock stretching by the slave. The FET is operating in reverse in that case - the effective drain and source are swapped, but it will still work correctly.

kevin

I'm currently using 5K? pullups, here is what things are looking like:

Levels look ok, things are going all the way to ground when needed and all the way to 3.3V or 5V respectively. There is sometimes a negative spike af ter a data pulse on the master side (you can see it in the scope trace abov e). The rise-time is...ok...looks like around 1.5us if you include that mu sh at the top.

Keep in mind, this is 'working' since I have the scope probes attached. Th e slaves don't respond otherwise. Actually the DACs don't seem to care, bu t the ADCs don't respond unless I probe or touch the SDA line on the slave side (5V). Wouldn't it be nice to 'see' what is going on without touching the circuit with probes?

I have room to go harder on the drive by lowering the pullup resistance as John suggested...but it seems to me that the fact that it works if I add ca pacitance, means that I want to slow down the the data vs. the clock. Woul d it be reasonable to increase the pullup on the clock, but use a higher re sistance on the data? Easy enough to try a few different resistors at the bench and see what happens.

Normally I wouldn't mind using a level shifting IC, but if I can avoid a bo ard rev here it would make me very happy.

Am I missing something obvious about the way I am clocking out data? I don 't have a ton of I2C experience and am kind of an idiot...my other boards m ay just work 'accidentally'.

Thanks, everybody, for your help.

On Thursday, October 6, 2016 at 11:18:03 AM UTC-7, DemonicTubes wrote: ...

What's causing that glitch on the falling edge of the 5v clock in the last image?

That will be worse without the probe.

What is the 3.3v clock like?

kevin

On Thursday, October 6, 2016 at 12:09:37 PM UTC-7, kevin93 wrote: ...

Ignore that - I see you already commented and have the 3.3V clock.

I don't see how it can cause a problem in this case but one issue with using FETs for such purposes can be their very high capacitances - probably 10's of pF between D and S when off.

kevin

I don't really know. I want to say coupling between the data and clock lines, but I took pains to not route them together on the PCB, and they are not on adjacent lines in the ribbon cable to my test setup.

I'm half tempted to just hang 47pF caps off everything and pretend nothing is wrong.

Hi

The falling edge is very jumpy in the middle, that can cause double- clocking.

The MOSFETs you use are (according to the datasheet) designed for switching relays and small motors. They have a 10k resistor in the gate and that makes them very slow to respond to the gate signal. Also they have Zener diodes from gate to drain, which adds a large parasitic G-D capacitance. On the falling edge this can produce weird effects.

Try the same circuit with a pair ordinary small signal MOSFETs like

Also see if you can pull up the 5V side a little stronger (3 to 5 k).

Dimitrij

Dimitrij, I think you are on to something!

You are totally right, and that is why I stock those MOSFETs in the first place. I only used them here because their specs were 'good enough' (ha!) and they are the tiniest dual FETs I have on hand.

I assume you meant 2N7002s, and frustratingly, they are offered in a dual package with the same pinout...except in SOT-363 instead of TSOT-26 (or TSOT-23-6). So close.

I have some 2N7000s in TO-92 I _might_ be able to tack in to test, though. If I get enough time this afternoon I'll give that a shot.

I will also try even stronger pullups to see if the situation gets better or worse.

Thanks!

As other posters have mentioned the falling clock edge looks suspect.

I don't see a close-up of the 3.3V clock but assume there is no dodgy falling edge.

The DMN61D8 gives some hint of terminal to terminal capacitance but not Drain to Source capacitance. I would suggest the 'glitch' is feed-through before the device is able to turn on.

Reducing the 5V load would therefore have minimal effect. The I2C spec require suppression of spikes lasting less than 10ns, but as others here have suggested not all devices follow I2C specs.

The only solution I can see is to slow the clock falling edge, preferably on the 3.3V side. If the master is a micro, you may have some control over the GPIO properties for a slower transition?

Are you sure the master isn't 5V tolerant so you can do away with this level translation?

Slugging the clock on the 5V side would be a last ditch attempt. A higher on-resistance, smaller geometry FET would be another another possible solution in conjunction with with a reduced 5V clock capacitor to ground.

Hi

Sorry, Of course I meant 2N7002, not 2N2007.

I think the failure mode in your circuit basically looks like this:

(on the falling edge)

1. The master strongly drives the line LOW while the slave side is still mostly at 5 V

-> Drain is HI, Source is rapidly falling

1. The FET sees a large POSITIVE dV_ds/dt
2. The large gate capacitance (plus zener) turns the dV_ds/dt into a large dV_gs/dt
3. This instantly (rapidly) turns the FET on
4. The FET discharges the slave line by pulling a very strong (compared with pullup) peak current
5. The discharge current sends a Dirac-like pulse down the line into the I2C slave direction
6. In the mean time the falling Drain line, almost turns OFF the FET via C_gd coupling (I_d drops)
7. The Dirac pulse comes back reflected off the end
8. The pulse (from a very low trace impedance) sends the Drain LOW very fast (few nanoseconds)

-> Source is slowly falling, Drain is rapidly falling

1. The FET sees a large NEGATIVE dV_ds/dt
2. The parasitics turn that into a dV_gs/dt
3. That Gate was already charged only very weakly (to the point where the FET becomes linear)
4. The Gate is fully discharged by dV_gs/dt and the FET turns OFF practically completely
5. Steps 2 to 4 repeat but with smaller amplitude
6. The 10k resistor in the Gate connection slowly takes over and starts charging the Gate again

After this the whole thing slowly settles into normal operation.

The basic problem seems to be that the Gate is allowed to do what it wants by following dV_ds/dt through the large C_gd coupling. The large resistor of 10k can't do anything about it, and the Zener between D and G only adds capacitance and recovery time, making the effect worse.

In the intended application (driving relays) the effect is intentional, in grounded Source configuration it automatically limits dV/dt and makes the relay coil voltage switch slowly, electrically "quiet".

Something that has no large gate resistor (and no intentional large Gate to Drain coupling) should work better in your application, I'd think.

Dimitrij

P.S. Also you can limit dV_ds/dt to more manageable levels by placing a series RC circuit (100 Ohm in series with 47 pF) between D and S.

This somewhat lowers the total dV/dt on the I2C slave side, but it can help to (somewhat) get rid of the ringing for any type of FET you use.

I beleive drain current is a function of V and not dv/dt?

I've not known a rapidly changing gate voltage below threshold turn on a MOSFET. There are of course capacitive feed-through effects.

Agreed.

I've not heard of Dirac-like pulse and have even googled it to no avail.

I initially dismissed that reflections may play a part here given that any signal travels at around 20cm / 1ns. Perhaps the OP can enlighten us to the track lengths involved?

I was assuming the threshold (being not very high) to be reached by the feed-through effect from drain to gate.

Sorry, that was rather a sloppy reference. I meant this:

Of course the real thing is likely to look more like a step than like a delta impulse. Though, at high frequencies (some 100s of MHz) the distinction could become somewhat a moot point.

Well, who knows? The oscillogram by the OP was taken at 1 us / div timescale and the whole impulse part just takes 2 pixels in the horizontal direction (in the last picture). The most steep risetime is difficult to judge, it can be anything, but it's most likely in the upper single or lower double digit nanoseconds. Anyway, it was looking pretty fast to me at first glance, and there is not enough resolution to definitely exclude reflections.

Of course, I could have over-estimated the speed (in this case, there's no need to consider the 5V-side part as a transmission line segment and all that...)