Teensy 3.5 pulls down I2C lines when off

Status
Not open for further replies.

merrillii

Member
Hi - looking for some advice on how to get around a problem I see when the Teensy 3.5 is off. My project is set up as a teensy acting as an i2c slave hanging off a cable from the master (which is also a Teensy 3.5). The i2c bus is shared among several other devices. The slave has 2.2kOhm pullups to the Master's VCC of +5V (which also comes down the cable). The slave Teensy, however, is powered off a different 5V supply than the master. The slave Teensy has the USB power line cut so it can be externally powered.

When the Teensy slave's 5V supply is ON, all the communications work well, including communications to other i2c devices. The rise time of the clock and data lines look good so the pullups seem right. However, when the Teensy slave's 5V supply is off, it drags down the i2c bus to about 400mV. It seems almost like it is trying to draw power from the lines or something. When it's in this state, no other i2c device can communicate with the master since the bus is being dragged down.

I'm sure an i2c buffer chip would prevent this but I'm wondering whether there are any simpler solutions available, since kludging a chip onto my slave board won't be very pretty. Does anyone have recommendations?

TIA

Best,
Dennis
 
I2C is not designed to handle such scenarios. It was invented by Philips to allow communication between ICs on the same circuit board and with common power supply, i.e. in TV sets. Leaving a unpowered Teensy on the I2C Bus might even damage the Teensy since all the available current on the I2C bus will flow through the internal pin protection Schottky diodes (which btw explains the 0.4V remaining potential).
If you insist on maintaining your use case, fast optocouplers for both, the SDA and SCL lines might be a solution.
 
The data sheet claims that there are ESD protection diodes to ground only so there is no clamp to Vdd causing trouble.

Your pullups on the disconnected slave board are odd. I2C requires just one set of pullups which are best located at the master. It sounds like you put redundant pullups on each slave. If that is the case, then you have a connection to 5V via the I2C signal lines. Which are attempting to supply power to the 3.3V regulator through those pullups. The regulator isn't working well but it is turning those pullup resistors into pull downs.
 
What do you mean by "no external changes are allowed?" I never said that. I'm saying the Teensy, when unpowered, drags down the i2c bus lines. I'm looking for a solution for that. Presumably when power is removed from the processor the input circuit of
the IO lines is such that it will drag down the bus.

Imagine a black box that has the teensy slave in it. The box has its own power supply and a separate cable to the master that carries the i2c lines. The master also has other i2c things attached to its bus. Now if you turn the power off to the slave box, it will drag the whole bus down and not allow the master to communicate with any other devices. That doesn't seem like correct behavior. The correct behavior would be to NAK the slave address when requested making proper use of the pullup resistors.

A solution to this, as I mentioned, is the addition of an i2c buffer chip like PCA9515 with enable tied to the power line. This would isolate the teensy from the i2c bus. However I'm wondering whether there may be simpler solutions?
 
You said you don't want that chip, so I assume other chips are not wanted, too.
Add a mechanical switch :) Or use a 2nd I2C bus. Or use the UART instead.
 
The data sheet claims that there are ESD protection diodes to ground only so there is no clamp to Vdd causing trouble.

Your pullups on the disconnected slave board are odd. I2C requires just one set of pullups which are best located at the master. It sounds like you put redundant pullups on each slave. If that is the case, then you have a connection to 5V via the I2C signal lines. Which are attempting to supply power to the 3.3V regulator through those pullups. The regulator isn't working well but it is turning those pullup resistors into pull downs.

Thanks - I think that the internal sckottky protection diodes may indeed be what I'm seeing. I don't quite see why it matters where I place the pullups since the circuit is the same (just a passive cable between it). I do have two sets of pullups but those should just look like a parallel resistance. The timing looks fine when the power is on so the pullups don't appear to be mis-sized even when they are in parallel. If I removed the pullups from the slave teensy then wouldn't the pullups on the master just try to supply power to the regulator in the same way? I guess the only solution will be a buffer or opto-coupler in this case. Maybe a MOSFET circuit of some sort to shut off current to the pin if VCC is not high...
 
If I removed the pullups from the slave teensy then wouldn't the pullups on the master just try to supply power to the regulator in the same way? /QUOTE]

No. The path is I2C -> resistor -> 3.3V regulator input. Your other resistors are on the wrong side of the disconnect so aren't connected to the regulator.

Once again, the data sheet says that there are no diode clamps to Vdd. Just Vss.
 
I assume you guys are referring to thisfom the datasheet:

"All 5 V tolerant digital I/O pins are internally clamped to VSS through an ESD protection diode. There is no diode connection to VDD. If VIN is less than VDIO_MIN, a current limiting resistor is required. If VIN greater than VDIO_MIN (=VSS-0.3V) is observed, then there is no need to provide current limiting resistors at the pads. The negative DC injection current limiting resistor is calculated as R=(VDIO_MIN-VIN)/|IICDIO|."

So, I guess what's happening is when power is shut off, Vdd goes to 0V and then Vin (through the i2c connection on pin 18/19) stays at 5V. So there is a connection between the input pin and Vss (ground) but it only 5V through a diode so why would current flow? Even if it did flow, it would be limited by the pullup resistor. And, since there is no connection between the pin and Vdd why would it try to power the device? I'm thinking the input looks like this picture but it must be different. Any references would be appreciated. I can't find more information in the datasheet about this...

IMG_20190110_175716227~2.jpg
 
If I removed the pullups from the slave teensy then wouldn't the pullups on the master just try to supply power to the regulator in the same way? /QUOTE]

No. The path is I2C -> resistor -> 3.3V regulator input. Your other resistors are on the wrong side of the disconnect so aren't connected to the regulator.

Once again, the data sheet says that there are no diode clamps to Vdd. Just Vss.


I just don't see how that can happen. The +5V on the pullup resistor comes from the master and is not connected to Vin in any way (it's not tied to the +5V from the slave power supply). Since the input pin is not connected to Vdd, I don't see how the regulator can be trying to draw power.

Here's a diagram to illustrate my setup:

IMG_20190110_182203218~2.jpg

Very grateful for the help here - trying to understand why this connection scheme has the effect that it does.
 
I assumed that you were running 5V to the Teensy to provide power. There really is no other reason to do so since those pullups are best located with the master.
 
Running clock and data through a double pole relay with the coil energized by the slave power supply would be a quick and easy solution.
 
Running clock and data through a double pole relay with the coil energized by the slave power supply would be a quick and easy solution.

Yeah, or a FET circuit would do the same. Thanks for the idea.

I'm still having trouble understanding why this is even necessary...
 
I assumed that you were running 5V to the Teensy to provide power. There really is no other reason to do so since those pullups are best located with the master.

Thanks, as you can see it wouldn't matter if I moved the pullups to the master. There appears to be some sort of passive circuit on the GPIO inputs that is causing this. I don't understand how a diode to ground would be the problem though...which is what the datasheet is saying (if I'm understanding it correctly).
 
I'm still having trouble understanding why this is even necessary...

Most unpowered IC's have parasitic diode paths that normally remain reversed biased when the device is powered. The current path to Vdd is probably through the pin driver circuit and/or other circuits for the multiple uses of the pins in question.
 
Most unpowered IC's have parasitic diode paths that normally remain reversed biased when the device is powered. The current path to Vdd is probably through the pin driver circuit and/or other circuits for the multiple uses of the pins in question.

I agree that it must be the case that there's some internal connection between pin 18/19 and Vdd. However I'm having a hard time squaring that with the note in the datasheet saying there is no diode connection to Vdd. I guess that doesn't say there is no connection at all to Vdd but if that's what they mean it's kind of misleading.
 
I've managed to solve this kind of parasitic diode path problem before... just inline a resistor.
 
I've managed to solve this kind of parasitic diode path problem before... just inline a resistor.

Thanks, a current limiting resistor on the input pin sounds like a simple fix. Could have some effect on the i2c signal though. Do you remember what value you used?
 
If you only write to the slave, you may get by with resistors. If you read from the slave then there will be a resistor voltage divider when the slave drives the line low and your voltage low margin will be less to non-existent.

The parasitic diode issue is so common that you should pretty much expect it to happen. My current project has a 5 volt processor hooked to a 3.3 volt nokia display via a CD4050 voltage converter ( also powered with 3.3v ). When I forget to turn on the 3.3 volt supply, the display shows a faint image of the correct information. So somehow the IO lines are powering both the display and the CD4050 with enough voltage to allow the display to work at 1 mhz spi. Strange but not unusual.

Edit: I forgot about the ACK bit and clock stretching, so resistors probably won't work for I2C bus.
 
Last edited:
If you only write to the slave, you may get by with resistors. If you read from the slave then there will be a resistor voltage divider when the slave drives the line low and your voltage low margin will be less to non-existent.

The parasitic diode issue is so common that you should pretty much expect it to happen. My current project has a 5 volt processor hooked to a 3.3 volt nokia display via a CD4050 voltage converter ( also powered with 3.3v ). When I forget to turn on the 3.3 volt supply, the display shows a faint image of the correct information. So somehow the IO lines are powering both the display and the CD4050 with enough voltage to allow the display to work at 1 mhz spi. Strange but not unusual.

Edit: I forgot about the ACK bit and clock stretching, so resistors probably won't work for I2C bus.

Thanks. I guess the only real solution is an i2c buffer, opto-isolator, or mosfet/relay circuit.
 
Status
Not open for further replies.
Back
Top