Main Site Documentation

Pin Protection Advice


I need to protect the mainboard pin (PIN4) in the attached simple circuit. U$3 will connect to U$4 either through an external button or long wires connected to anything else that create or break the circuit. Whatever is attached to the U$3 & U$4 should never have any power but worried about static charges or other accidental surges. I’ve been studying the various ways to do this and I think every example I see is different. I see the Load module uses Schottky diodes but other examples use Zener diodes.

I’ve mostly settled on the attached design where D13 is a 3.43V Zener diode.

Will this give me the protection I need? If not, what would you recommend instead? I’m interested in all opinions. My board is getting crowded and I need the smallest package to prevent having to step up to the next tier in board pricing. Of course it needs to also be the cheapest solution.



Do none of you electrical genius’ want to discuss this? I’m trying to determine what is “enough”? If I look at this article, it shows putting Schottky’s on the ground & +5V side plus a capacitor. My board would have to grow significantly to do all this (x7 pins). I don’t see any other modules doing this much. So, I think this is a good conversation to have.


Would a transient voltage suppressor diode array work for you? Something like this perhaps (only an example):

The trick will be finding one with the appropriate clamping voltage. The product above has 6 channels, so you can protect 6 pins, but it’s not exactly a good fit because the clamping voltage is set to 7V. You probably want to look for a TVS that has a clamping voltage of 5V. Just an example.

[Edit:] This one might be more suitable. It has 8 channels and a 4.5V clamping voltage:


I wasn’t aware of those. That looks like a great solution. I’m protecting FEZ pins which are all 3V3. By clamping voltage I assume you’re talking about what is referred to as the reverse voltage? This one looks like it should do the job for all 7 pins. Agreed?


Looking through the datasheet for the ON Semiconductor part you indicated, the clamping voltage is 8.8V, so it’s a little too high for a digital pin. The Vishay Semiconductor part in my modified post may actually work nicely, since its clamp voltage is below the absolute maximum rating for a digital input pin.


That package is certainly nicer. Just to make sure we’re on the same page, though. I’m looking for one to protect a 3V3 pin. Is that the right one or is that for 5V pins?


It should work for 3.3V pins, assuming the pin is 5V tolerant. In practice, the NXP pin’s absolute maximum rating is 5.5V, I believe. Unless of course the particular microcontroller you’re working with is not 5V tolerant, then we have to look at something else.

[EDIT] The reverse standoff voltage is the critical parameter. This is the point at which the TVS will start clipping the input voltage. I stand corrected – your ON Semi device is actually better suited for 3.3V pins than the one I recommended, since its standoff voltage is right at 3.3V. Sorry, I was juggling other things while browsing through the datasheets and got the devices mixed up.


This should work nicely. If someone’s board gets blown up then we’ll find out otherwise :wink: Not a bad price either. Thanks!


A potential problem I’ve run into… This chip will require a maximum of 7mil traces. I see a forum response from DFRobot that says they support 6mil traces but their .dru file is enforcing 10mil traces. Does anyone have experience using traces this small with DFRobot? Did you send in the design despite the failures to pass the DRC checks? I’ve sent them an email but their on holiday for the next two weeks… I think the Chinese have more holidays than they have work days. :wink:


@ ianlee74 - yes to smaller traces…you have the wrong dru file :wink:


I just downloaded it 10 days or so ago. I’ll look for a newer one. Mine is named “DFRobot_Eagle_Rule_v0.4.dru”. What is yours?


Hmmm… I checked the settings imported by the DFRobot .dru file and they actually appear to be correct. Perhaps there’s an issue with Eagle or I’m just totally misunderstanding this DRC error… If you create a 7mil trace and run the check does it not complain?


If you create a 7mil trace, with a 6mil DRC rule, then it will not complain, because it’s not less than the DRC rule. If you do a 5mil trace, it will complain.

(that’s how it should work. 6.4.0 has broken many things in my experience, but I haven’t run a DRC since the “upgrade” )


That’s what I would expect but that isn’t what appears to be happening. I just want to confirm that someone else is also seeing this and it isn’t a problem unique to me.


Are you sure your traces are 6mil and not 6 in some other units?


Yep. They’re actually set to 7mil. I stepped in 1mil increments from 6 to 10mil before they finally passed. I’m using Eagle 6.4.0 Light.


I still have 6.3.0 and can check your file if you want.


do the “simple” test. Open the DRC page, Sizes tab, set it to 11 and check. Set it to 6 and check. You should get a “Width” alert. I just tried it without opening a DRC file, just using the defaults Eagle seemed to have, and if I have DRC width to 10, and a sample track width of 11, the DRC passes; if I change trace width to 9 I get the DRC error… this is 6.4.0 and an existing board


Try setting drc width to something less than 10. Mine seems to be defaulting to 10 and ignoring the set width.


Minimum Width and Minimum Drill may be overwritten by larger values in the [em]Net classes[/em].

Check Edit->Net classes…