High speed data lines to a slave PCB equals MCU death

[matt6ft9]

There is an existing LED master and slave PCB configuration.  (not my design)
The master PCB provides power and data to a slave PCB.  In the design, there are four wires on a connector going from the master to the slave PCB:  Power (either 12VDC or 24VDC), clock (5V), data (5V), and ground.  The clock is running at 100KHz.  The cable length is about 5cm. 

The issue is this:  If the 4 pin connector is unplugged, it sometimes damages the data/clock lines.  This seems to happen when the ground is lost first.  My first thought is to use Zener diodes to protect the clock and data lines, but Zener diodes have relatively high capacitance value and it tends to not get along well with the 100KHz.  How should the clock and data lines be protected from the 12/24V when exiting the master PCB and entering the slave PCB?
Matt

[nctnico]

Series resistors and varistors or TVS diodes. The beauty of varistors is that they also have a lot of capacitance so they form a filter together with the series resistor. Also make sure to use Schmitt-trigger buffers (74HC14 for example) on the signals to increase noise immunity.

[Fungus]

Make the 12/24V pin shorter so it always disconnects first.

(ie. chop the end off it)

[langwadt]

There is an existing LED master and slave PCB configuration.  (not my design)
The master PCB provides power and data to a slave PCB.  In the design, there are four wires on a connector going from the master to the slave PCB:  Power (either 12VDC or 24VDC), clock (5V), data (5V), and ground.  The clock is running at 100KHz.  The cable length is about 5cm. 

The issue is this:  If the 4 pin connector is unplugged, it sometimes damages the data/clock lines.  This seems to happen when the ground is lost first.  My first thought is to use Zener diodes to protect the clock and data lines, but Zener diodes have relatively high capacitance value and it tends to not get along well with the 100KHz.  How should the clock and data lines be protected from the 12/24V when exiting the master PCB and entering the slave PCB?
Matt

there are lots of different protection diodes meant for various high speed interfaces

http://www.onsemi.com/PowerSolutions/parametrics.do?id=248

[georges80]

Firstly 100KHz is not high speed... and certainly not with only 5cm of cable   

Secondly, sounds like a very poor design. Once you lose ground your data lines become the ground path for your +12V or +24V on that connector.

So, you need to deal with the current path due to lost ground. Series resistors, ESD/spike clamp, buffer/schmitt etc.

cheers,
george.

[matt6ft9]

Fungus - Unfortunately we are stuck with the 4 pin Weidmuller connector/terminal block for this design.  (it’s what the customer wants)  So, making the power pin shorter is out of the question for 1000’s of units.
The MCU on both the master and slave is an ATTINY87.
Series resistors and the on-semi TVS diodes sound good, it would limit the current.  The ESD7351 has a rating of 0.6pF max to ground.
Would optocouplers be a viable option?

[georges80]

Opto on clock and on data would work assuming your clock/data are unidirectional.

cheers,
george.

[georges80]

If you are using I2C (sounds likely):

http://www.ti.com/lit/ds/symlink/iso1541.pdf

cheers,
george.

[Fungus]

Would optocouplers be a viable option?

No, because I2C is bidirectional.

But... if it's just Tiny85->Tiny85 communication then you could develop an I2C-like protocol that works with unidirectional lines. It wouldn't be very difficult.

The simplest way is just to limit how much current can flow along the I2C lines. Restrict it to a level where things don't break. According to Atmel the clamping diodes on AVR chip I/O pins are supposed to be able to handle 1mA (that's probably where the current is escaping).

[nctnico]

In this case varistors will be better. It doesn't hurt to have 100pf on I2C lines going between boards. Also: is this bit banged I2C or does this chip has a real I2C interface. When bitbanged: duck and run because the logic levels on the attinys are terrible and have caused a lot of problems in one of the designs I inherited in a similar application.

[georges80]

Would optocouplers be a viable option?

No, because I2C is bidirectional.

But... if it's just Tiny85->Tiny85 communication then you could develop an I2C-like protocol that works with unidirectional lines. It wouldn't be very difficult.

The simplest way is just to limit how much current can flow along the I2C lines. Restrict it to a level where things don't break. According to Atmel the clamping diodes on AVR chip I/O pins are supposed to be able to handle 1mA (that's probably where the current is escaping).

You did LOOK at the TI part didn't you???

cheers,
george.

[matt6ft9]

The TI part would be the ideal solution, but the cost is $2.03 USD in reel quantities at digikey.  Ouch.  For this assembly, the $2 increase in the BOM is out of the question.  Building down to a price sucks.

The data and clock might be going only one direction, from the master to the slave.  (I’m the engineer working in manufacturing, so I don’t know all of the details)  I do have access to the schematic, data is on pin 19 and clock is on pin 14, so it looks like it bit-bang communication.

[georges80]

Many of the AVR chips have I2C hardware or SPI etc.

So, first step is to determine EXACTLY what communication is actually being used. Your software folk should be able to tell you what protocol they are using.

Lot's of ways to opto isolate I2C. Search with google brings up lots of ways/options.

http://www.embedded.com/design/prototyping-and-development/4025023/Opto-electrical-isolation-of-the-I2C-Bus

is just one example.

But, 1st you need to figure out what that 2 wire link actually is...

cheers,
george.

[nctnico]

Optical isolation is only useful if you want no common ground! Usually it is cheaper to use differential signalling like RS485 but in this case the main problem is signal protection so series resistors, varistors and have inputs with a large hysteresis. The cable is only 5cm long so no need to over engineer this into a complex circtuit!

[Ian.M]

The first thing I'd try would be heavy duty Schottky clamps at both ends, capable of carrying the whole 24V rail load current of the slave board.  The upper clamps on the end that supplies the 24V *MUST* *NOT* dump any current into the Vdd rail, so a stiff shunt regulated dedicated clamping rail slightly below Vdd must be provided.  There are various ways of doing this, depending on the accuracy required, the simplest of which is a beefy Zener (+ a pullup resistor in series with a Schottky diode to keep it biassed).  It will probably also need 100R resistors in the I2C lines between the clamps and the MCU to limit the current into the MCU's protection diodes when clamping fast transients.

[bson]

It would be useful to understand exactly why losing GND first is a problem and what the mechanism leading to the failure is.  The solution might be as simple as putting a small 16V 100uF cap between 5V and GND on the slave board to keep the voltage from collapsing immediately and introducing a controlled bleed.

[Ian.M]

Its most likely the slave 0V rail rising and all its load current being dumped into SCL and SDA via the internal low side ESD diodes of the slave ATtiny87.  A large cap will *NOT* help as that will just cause it to blow the ESD diodes if its hot-plugged and power mates before ground.

[matt6ft9]

ian.m - You stated the problem very well, much better than what I did. 
I'll try to find out more details about the communication on Monday.  (and also try some different heavy duty schottky clamp/zener configurations)

[C]

Think ian.m statement is true.

If you fix the slave, then this problem shifts to the master.
To be safer both need protection.

[Delta]

Just stick some series resistors on the clock and data lines. KISS!