This web site is being maintained by John R. Barnes, who was the President and Chief Engineer of dBi Corporation from 2002 to September 30, 2013, when we closed because ObamaCrap made it too expensive for us to remain in business.

John R. Barnes
published on the Printed Circuit Design magazine web site in November 2001

Return to Part I

The first half of this article ran in the July 2001 issue of Printed Circuit Design. That section discussed the origin of ESD and possible defenses against it, including proper layout, enclosures, shielding, grounding and bonding. This half of the article will cover cable connectors, suppressors, component selection, "watchdog timers" and ESD testing.

Cable connectors

Connectors on cables are prime targets for ESD arcs and the cables themselves are primary targets for inductive and radiated coupling. To make cables ESD immune:

F1 Provide one entry area for all cables, near the center of an essentially continuous conductive panel-not on an edge or close to a corner.

F2 Use female connectors on the equipment for ESD-susceptible signals, or recess these contacts.

F3 Keep signal contacts >= 2.2 mm (0.087") away from any metal that can be hit by an ESD arc or carry ESD current. This will help prevent secondary arcing.

F4 Choose shield material, cable-backshell metal and the mating connector's metal (see Table 2) to minimize corrosion:

F5 Use shielded cables, or choose connectors that will accept shielded cables.

F6 Prefer foil- or foil-and-braid-shielded cables instead of braid-shielded cables.

F7 Cable shields should be >= 0.025 mm (0.001") in thickness, because very thin shields can be hard to connect to connector backshells reliably.

F8 Tie cable shields to chassis ground at each connector. If you don't have chassis ground at a connector, tie cable shield to circuit common with:

F9 Connect cable shields to chassis grounds with a 360-degree bond if possible. A short, fat connection to chassis ground within 40 mm (1.6") of the connector may be acceptable (length < 5 * width, preferably < 3 * width).

F10 Terminate cable shields at the metal enclosure or shield. Do not bring them inside.

F11 Unshielded portions of the cable should be <= 40 mm (1.6") in length.

F12 Avoid pigtails and drain wires on shields. Connecting the shield to a connector pin and then having a wire from the connector pin to chassis ground inside the enclosure is especially nasty from an ESD standpoint.

F13 Minimize loop areas inside the cable; use a ground wire for each signal wire or a few signal wires.

F14 Try to use the following:

F15 Provide at least one ground wire next to each signal wire in flat cables (S-G-S-S-G-S-S-G-S), with sensitive signals at the center of the cable.

F16 Handle extra wires in a cable by:

F17 Place ferrite sleeves on cables so that they encircle all the ground/power/signal wires, but not the shield or shield drain wire or wires. This is most effective if the ferrite is a close fit to the cable.

F18 Keep I/O cables well away from ground wires, ground straps and other pieces of the enclosure that may carry ESD current.

F19 Route cables over continuous metal inside metal enclosures and shields. Do not route a cable across a seam, slot, or hole-the magnetic field inside the enclosure can be 50% higher than outside because of diffraction effects.

F20 Use dimpled contacts between connector shell and the mating connector.

F21 Provide at least one ground wire per five signal wires in a cable.

F22 Keep cables as short as possible.

F23 To ensure high optical coverage and continuity for cable shields:

F24 Consider using a shielded power cord with its shield attached to chassis ground.

F25 Keep internal cables at least 50 mm (2.0") from seams and slots in the enclosure.

F26 Put clamp-on ferrites on internal cables and use flat clamp-on ferrites on ribbon cables.

F27 Choose connectors with dimples for connecting metal backshells to the bodies of mating connectors.

F28 Strip back the metal strength members or armor on fiberoptic cables, well away from the connectors.

Circuit Design

Circuits should be designed with protective components that can be left unpopulated or populated with 0-ohm resistors. The following will help make your circuits immune to ESD:

G1 Do not use a circuit or system that can enter an unlimited-duration wait/disable state.

G2 Avoid edge-triggered logic.

G3 Provide and check parity/framing on data wherever possible.

G4 Latch data with strobes, not clock edges.

G5 Do not connect sensitive inputs to ESD-susceptible lines (i.e., resets/interrupts to a long cable).

G6 Tie unused inputs and unused bi-directional pins, high or low, through resistors.

G7 Isolate signals from the outside world with optoisolators or transformers.

G8 Use differential signals wherever possible.

G9 Provide for common-mode chokes on differential signals.

G10 Use low-impedance circuits in area that are subject to charge injection or capacitive coupling.

G11 Put peripheral chip resets under software control.

G12 Put filters on resets, interrupts and edge-triggered signals.

G13 To keep common-mode noise from changing to differential-mode noise, put the same protective circuitry on all the signals coming from a connector.

G14 Provide for a common-mode choke for all the ground/power/signal wires in a cable, to be installed between a connector and the electronics.

G15 Consider using optoisolators with a transparent Faraday shield between the input and output.

G16 Ensure that power monitors won't be triggered by very short ESD pulses.

G17 Design peripheral circuits using "hold" or "ready" so that resetting will restore normal operation.

G18 To prevent firmware from hanging or getting lost, support a containment set approach in hardware. (Remember that temporary data errors and stretched out loops may still occur.):

G19 Beware of "trap states" that are difficult to get out of:

G20 Provide for filters on all signals that go off-board.

G21 Provide for filters on optoisolators driving/receiving offboard signals.

G22 Provide a way for the software to force a hardware reset of the processor and all peripherals as a last-ditch recovery effort.

G23 Defend critical outputs against transients, rogue programs, etc., by taking the following precautions:

Filters and suppressors

Filters and transient suppressors protect inputs, outputs and power nets. Low-pass filters are designed to reject noise above their maximum signal frequency, but because of parasitic capacitance and inductance, these filters are usually only effective from DC up to 100-1000 times their design frequency. To cover the 500 MHz bandwidth of ESD, several cascaded low-pass filters may be required, with design frequencies of the following: f (representing the desired frequency), 30*f, 1000*f, etc.

Filters are linear, so large ESD pulses put more noise into the protected circuit than small ESD pulses. Transient suppressors are highly non-linear and work by dumping excess current into a relatively safe ground. Thus they have little effect on ESD pulses below their limits and clobber all ESD pulses that exceed their limits. Combining filters with transient suppressors can be a very effective strategy.

To make filters and transient suppressors effective against ESD:

H1 Consider the maximum capacitance that can be placed on a signal.

H2 Choose components to withstand ESD voltages and currents:

H3 Place components close to the connectors to reduce the loop area. Connectors with capacitor arrays, ferrite sleeves and/or metal-oxide varistor (MOV) arrays built in are available but expensive.

H4 Use very short leads. Remember:

H5 Use series resistors or ferrite beads toward the ESD source and toward low-impedance drivers and receivers (may be the same part):

H6 Use shunt devices toward high-impedance drivers and receivers:

H7 Arrange this as:

H8 Use short, fat connections between shunt devices and chassis/logic ground (length < 5 * width, preferably < 3 * width).

H9 Treat all the wires in a connector the same to keep common-mode ESD noise from being converted to differential noise.

H10 Do not use components that are rated too close to the signal levels they are intended to protect.

H11 Choose transient suppressors that turn on within 1 ns:

H12 Arrange the filter/transient suppressor components and the wires to:

H13 Run a high-frequency capacitor from each wire to chassis ground at the connector for unshielded cables. Treat all wires the same, whether ground, power, or signals, to prevent turning common-mode ESD current into differential-mode noise.

H14 Put a high-frequency ESD filter after a power-line filter on the power cord.

H15 Design filters for > 40 dB attenuation from 100-300 MHz.

Component choice

Active components usually have the greatest effect on the equipment's ESD immunity. Beware of substitute and second-source components that may be functionally equivalent but lack the ESD-immunity of the preferred components.

Choose robust components that:

I1 Don't have to operate close to their design limits.

I2 Are just fast enough and just sensitive enough to do their jobs.

I3 Have high noise immunity and high noise-energy immunity.

I4 Use differential inputs/outputs instead of single-ended inputs/outputs if possible.

I5 Ensure read-back capability on internal registers (no write-only registers).

I6 Try to avoid programmable input/output chips. An error anywhere in their configuration can make them go berserk.

I7 Are immune to latch-up.

I8 Have enough noise margin that small series resistors on inputs and outputs will not hurt the signal levels.

I9 Choose a processor with a fixed set of interrupt vectors over one that takes the next instructions in memory as the interrupt address.

I10 Seek good immunity to ESD (see Table 3). Remember that:

Table 3: ESD Immunity of Electronic Devices
(from about 1985)
Device Type ESD Damage
MOSFET  10-200 V
Recording Heads  10-800 V
VMOS  30-1800 V
NMOS  60-500 V
GaAsFET  60-2000 V
EPROM 100-500 V
Laser Diodes 100-1700 V
JFET 140-7000 V
SAW 150-500 V
CMOS 150-3000 V
Op Amp 190-2500 V
PIN Diodes 200-1000 V
DRAM 200-3000 V
Schottky Diodes 300-2500 V
Film Resistors 300-3000 V
Bipolar Transistors 300-7000 V
SCR 500-1000 V
ECL 500-2000 V
Schottky TTL 500-2500 V

Watchdog timers

Watchdog timers are hardware devices that will reset and restart the processor if the software hangs. They protect the equipment from ESD, power-line transients and buggy software. Watchdog timers must do the following:

J1 Tie into the master reset to force a cold start (all data lost on restart).

J2 Tie into a non-maskable interrupt (NMI) to force a warm start (some data retained on restart), because interrupts could have been disabled by whatever clobbered the processor.

J3 Have an edge-triggered input, so that the software has to explicitly toggle the input to keep the watchdog from timing out.

J4 Provide a way for the software to monitor the watchdog timer.

J5 Provide a way to disable the watchdog timer in the hardware. This method must function during product development, ESD testing and servicing.

J6 Assume a viewpoint of mutual suspicion between the hardware and software.

J7 Be tested with a tight timeout during software tests to make sure that they won't time out during normal operation of the product.

J8 Be reset by the software regularly. You can increase coverage against errors if you make some hardware and software sanity checks before resetting the watchdog timer.

J9. Have a period:

J10 Be reset in as few places as possible, preferably in one spot in the main loop.

Preventive software programming

Properly designed software can greatly enhance the ESD immunity of a product by checking for errors and correcting them before they cause damage. This also makes the product much more robust in normal operation. The basic requirement is to cleanly handle abnormal operation, no matter what the cause.

Many of the suggestions below are just good programming practices. Some are explicitly aimed at protection from transient events like ESD. You will need to choose the suggestions most applicable to your products because they all require additional design, coding and testing over bare-bones software:

K1 Assume a viewpoint of mutual suspicion between software and hardware, and among software modules.

K2 Read critical inputs two or three times, several microseconds apart, and make sure that they match before using them.

K3 After writing out an output, read it back and make sure it matches what you had intended to write out.

K4 Maintain a copy of all output states in memory.

K5 At regular intervals:

K6 Provide a way to log abnormal events for dumping for later analysis (and for several events if possible, because one error could cause additional errors if the fix-up fails).

K7 Monitor a watchdog timer to make sure it was running before resetting it.

K8 Fill unused memory with NOPs, followed by a jump to an error handler.

K9 Fill unused memory with a multibyte instruction (such as an absolute jump or absolute call) with data bytes identical to the opcode.

K10 Aim all unused interrupt vectors at an error handler.

K11 Recheck hardware, ROM, RAM, all programs and all data after finding an error.

K12 Consider shutting down temporarily if the error rate gets too high.

K13 Try to re-establish the previous correct state after detecting an incorrect state; if this can't be determined, switch to the state that most likely causes the least serious problems and warn any attached units that you have just done an error-recovery operation.

K14 Restore the state of the equipment:

  1. Disable interrupts.
  2. Reset stack pointers.
  3. Reset FIFOs.
  4. Reset counters.
  5. Prevent transmission of suspect codes.
  6. Re-enable and restart timers.
  7. Reset pending interrupts.
  8. Refresh outputs.
  9. Inform host that you are restoring state.
  10. Fix whatever fails sanity checks.
  11. Re-enable interrupts.

K15 Check all data from humans for syntax and validity.

K16 Validate data when received, acknowledging correct data and sending an error code for incorrect data.

K17 Retransmit data if don't receive an acknowledgement.

K18 Re-validate data just before using it.

K19 Check input data for reasonable, valid values:

K20 Store critical data in multiple locations; periodically crosscheck these locations and fix mismatched data.

K21 Break large tables into fixed-length records with checksums.

K22 Use parity, checksum, CRC or ECC to check blocks of data.

K23 Use a maximum depth counter when searching linked lists.

K24 Have the real-time executive verify that the task is valid for that time whenever a task exits or suspends.

K25 Periodically verify stack is empty in main program.

K26 Verify stack is empty whenever a task finishes.

K27 Copy the new stack data to a second stack when you jump to a subroutine, verifying that the main stack and this copy match before returning.

K28 Write a token before entering a routine and check it before returning from the routine. (These tokens form a very useful audit trail for debugging weird problems and they should be included in the error-log data.)

K29 Check index registers and other important registers before using them.

K30 Check for an excessive count before entering a delay loop.

K31 Exit a loop containing an error if the count is outside the legal range for the loop.

K32 Work on a copy of a record and verify it before overwriting the original record in a database.

K33 Run watchdog routines to verify that periodic functions are being run and that the main program is probably OK; the main program in turn verifies that the watchdog routines are running.

K34 Check pointers and index registers against the bounds of arrays, stacks and heaps before using them.

K35 Put redundant pointers (double-linked lists), counts of entries and type/status identifiers into records so they can be checked/repaired easily.

K36 Provide a way to disable these ESD-immunity enhancements for ESD testing; this could be a specially compiled version of the software just for development.

K37 For ESD and EMC testing, create a version of the software that continuously exercises all functions without operator intervention.

K38 Provide an easy way to tell testing personnel that something weird has happened-LED, status display, etc.

K39 Tell the user if a serious error has occurred from which you cannot recover automatically.

K40 Put groups of NOPs periodically throughout a program, with each group as long as the longest instruction that the processor can execute. These will realign the processor with the code if the program counter gets messed up.

K41 Put a group of NOPs followed by a software interrupt between each pair of subroutines. The interrupt routine forces a reset of the processor and may toggle an output line to warn the user/programmer that a major program error occurred.

K42 Provide a hardware memory lock that requires a special sequence to write memory; an insane program thus is unlikely to corrupt memory.

K43 Trap any attempts to:

K44 Support a containment set approach in software. (See papers by Robert E. Glasser and Gerald M. Masson for more on this topic.)

K45 Check object code for the presence of self-test opcodes in data, tables, etc. If the program goes awry and executes one of these locations, the processor will have to be completely powered off and on again to recover.

K46 Design the program so that out-of-domain inputs will not affect program flow.

K47 Check code and data tables for instructions or instruction sequences that could accidentally:

K48 Set checkpoint flags as each critical function in a routine executes; verify that these flags are all set before exiting the routine.

K49 Increment a flow-check counter as each critical function in a routine executes; verify that this counter is correct before exiting the routine.

K50 Gracefully handle unintended interrupts.

K51 Put multibyte flag or flags (possibly encompassing all otherwise-unused memory) in each volatile RAM as a power-loss indicator and check these flags at reset:

K52 Periodically save state information to a disk, EEPROM or other non-volatile memory so that a restart loses a minimum of data.

K53 Poll peripherals instead of using interrupts.

K54 Choose or design serial protocols that will not permit one high in a long string of lows or one low in a long string of highs to be a valid code.

K55 Put a tag in common memory to detect random jumps in the program flow by implementing the following:

  1. Initialize the tag to zero in the main initialization code.
  2. At initialization for each function/block:
  3. For a section of inline code, recheck the tag at the end and return an error if it isn't the correct value.
  4. For looping code, recheck the tag inside the loop and return an error if it isn't the correct value.
  5. At the end of the function/block, set the tag to zero again.
  6. For critical outputs, consider requiring two output operations that must be performed in sequence and separated by a tag check.

K56 Check system invariants (variables that are not supposed to change, ROM contents, unused RAM, etc.) in idle task and reboot if any of these are incorrect.

K57 Ensure that the error detection and warm-boot process is fast enough that an error can occur and be corrected before the attached mechanism has time to do anything dangerous.

K58 Beware of peripherals that use an auto-incrementing/auto-decrementing/toggling index register to access internal registers. Explicitly set the index register immediately before any critical reads/writes to the chip.

K59 Check data tables, jumps and calls for sequences that could execute as HALT, WAIT, DISABLE INTERRUPT or other dangerous instructions. Shuffle the order of subroutines and functions to avoid these starting addresses.

K60 End each data table with a string of NOPs, followed by a jump to an error routine.

K61 Beware of "one-way" instructions-those that can only be reversed by a hardware reset.

K62 Run sanity checks before returning from a subroutine/function. Check for the following:

K63 Fill unused RAM with pseudo-random data, not all-ones/all-zeros; check these areas during error recovery to decide whether memory needs to be re-initialized.

K64 Calculate outputs using several sets of input sensors and control algorithms, and compare these for reasonableness.

Problems with equipment

Equipment with moving parts can become its own ESD generator. Printers and copiers are especially susceptible because they have to move paper and foils around. Problem areas include sliding parts, rolling parts, flexing parts, flowing liquids and airflow carrying particles or liquid droplets. Some effective ESD control techniques:

L1 Minimize the number of moving parts.

L2 Reduce the contact pressure/duration between moving parts.

L3 Make moving parts and their supports from antistatic materials and materials that are close together in the Triboelectric Series.

L4. Bleed charges off slowly with tinsel, antistatic brushes or ionizers.

L5 Use conductive grease on bearings and joints.

This is a test

ESD testing finishes up the process of designing electronic equipment for ESD immunity. We usually must use some ESD-sensitive components to meet our cost and performance requirements, so we will have to compensate with a multitude of other design details. ESD problems are very complex and finding cost-effective solutions almost always requires multiple test-fix-retest cycles. Our goal is to find the weak spots in our design-one by one or a group at a time-and then come up with affordable ways to eliminate or work around them. Many times we have several weak spots with similar vulnerabilities, requiring a combination of fixes to raise the product's ESD immunity.

For effective ESD testing:

M1 Start with indirect ESD tests, since they tend to cause upsets without damaging the equipment under test (EUT).

M2 Run indirect ESD tests with all the cables attached to the EUT and again with just the power cord, to determine whether the signal cables or the shielding/basic design is the culprit.

M3 Proceed to direct ESD tests only after attaining your indirect ESD targets, because direct tests may damage your product. This risk is reduced if the product has been partially hardened already.

M4 ESD-test all customer-accessible points:

M5 Test the product in its normal operating configuration and in its installation configuration.

M6 Start testing at 2 kV and work up in 2 kV steps until you have a failure or have exceeded your target by 1-2 kV:

M7 Do not install an ESD fix that seems reasonable and then remove it if it doesn't seem to affect the ESD immunity. You may have fixed the weakness you identified but run into another problem with similar vulnerability.

M8 Wait until you have gotten your test unit up to the desired ESD immunity and then remove the ESD fixes one at a time to determine which fixes or combinations of fixes are effective on your product.

M9 Turn out the lights and zap the product to try to see the discharge path if only a few spots seem to be vulnerable.

M10 Turn off software defenses, perhaps through a special build of the code, to harden the hardware before hardening the entire product.

M11 Provide a simple way to see that the product detected some kind of upset, perhaps some LEDs to indicate that:

M12 Test the software's error detection/correction capabilities with an emulator. To simulate ESD-induced changes, change the registers, stack-pointers, program counter and data in memory to random values. Then watch how the equipment responds.

M13 Hook an oscilloscope to an unused output pin. Pulse this pin once at one critical spot in your code, twice at another critical spot, etc. This gives you a visible idea about what your code does under ESD upsets. (There is a slight risk of the oscilloscope probe injecting ESD noise into your product.)

M14 Perform ESD tests before running EMC tests-the test equipment is much cheaper and easier to use, and hardening a product's hardware against ESD takes care of some 500 MHz of potential emissions/ immunity problems in one shot. A word of warning: beware of running radiated-emission tests on a unit that has gone through ESD testing. Even though the unit may still work, cumulative damage to the ICs can greatly increase the emissions over a "virgin" unit.

M15 Use ordinary aluminum foil and copper tape to mock up shields, gaskets, bonding straps, etc.

M16 If the equipment consistently passes when you hit a point a few times, then consistently fails when you continue to hit the same point slow down the pulse rate, you may be charging up a net or piece of metal that has a high-resistance discharge path, causing a false error.

M17 Check supposedly identical ports early in testing to see if one of them is more sensitive than the rest; the remainder of the testing can concentrate on just this one port from the group.

M18 Check PCBs and subsystems as early in development as you can. Solder an LED onto an output to indicate pass/fail status:

M19 Measure the effects of ESD on a cable using an oscilloscope with a current probe snapped around the cable.

M20 Measure the effects of ESD on a trace using a shielded current probe.

M21 Consider testing three configurations of your product:

M22 Have the product designers attend the ESD test:

M23 Check for paint, grease or other insulating films at seams and bonding points if the same problems seem to come and go as you add fixes.

M24 Test another unit or two if only one particular area is causing trouble:

M25 Hand-pick the chips for your ESD test unit or units if you have multiple sources for critical chips (microprocessors and chips driving/receiving off-board signals). Use critical chips from the leading vendors in chip technology because these are the ones most likely to be die-shrunk and thus most susceptible to ESD.

M26 Keep one or two of the originally approved units available for comparison in case field problems arise, or if production units show a sudden change in ESD immunity:

M27 Periodically recheck units taken straight off production if these differ significantly from units approved originally. This is especially important for life-support or mission-critical applications:

M28 Operate a piezoelectric charcoal lighter in the vicinity of your equipment for a quick and dirty check of ESD immunity.

M29Test all equipment to be used in the U.S. with 15 kV air discharge. Many areas in the U.S. are much drier than in Europe.

M30Snap ferrite sleeves onto cables that run between boxes (close to the connectors) as a quick way to determine whether ESD is entering by way of the cables or through other paths.

M31Use an electrical fast transient (EFT) generator driving a current probe to couple transients onto a wire/trace that you suspect is picking up ESD. By slowly increasing the transient voltage while monitoring for failures you can find the dynamic noise-immunity of the receiver.


Once the design has been approved, try to avoid switching to "upwardly compatible" chips during production. These newer chips are usually faster and more sensitive than the chips you started with, causing new emissions and immunity problems. Make arrangements with your suppliers for early warning of die shrinks or other changes that could affect ESD-immunity. Test samples of the new parts. If they degrade your product, make a lifetime buy of the older parts before they go out of production.

Immunity from ESD is becoming a given in electronic products, as many such products now must meet legal or contractual ESD immunity requirements. But aside from the benefits of protecting the products from the hazards of ESD, designing products for ESD immunity makes them more robust in normal operation, thus enhancing their perceived quality. Achieving good ESD immunity can require the cooperation of mechanical engineers, electronic engineers, PCB layout folks and programmers. This is much easier to accomplish if ESD immunity is considered throughout the design of a product instead of treated as an afterthought. A little extra time spent during the design can preclude a lot of wasted money and time later on.

John R. Barnes is an advisory engineer currently developing controllers for digital office products at Lexmark International. For the past 11 years, John has worked for IBM and Lexmark as a hardware designer in the networking area. He is the author of "Electronic System Design: Interference and Noise Control Techniques."

Major references (The full list of references, including ones that were found after this article was written, may be downloaded from

Major resources:


dBi Corporation was a one-man test house (testing laboratory) based in Lexington, Kentucky, testing a wide variety of commercial electronic products for electromagnetic compatibility (EMC), electromagnetic interference (EMI), and electrostatic discharge (ESD) under its ISO 17025 accreditation. dBi was founded in Winchester, Kentucky in 1995 by Donald R. Bush, shortly after he retired from 30 years service with IBM Lexington's/ Lexmark's EMC Lab. John R. Barnes, who'd worked with Don at IBM Lexington and Lexmark, bought dBi in 2002 after Don's death, and moved the company to Lexington, Kentucky. John closed dBi at 11:59pm EDT on September 30, 2013, because ObamaCrap had increased operating expenses to the point that we could no longer afford to remain in business.

We'd like to thank all of the clients who chose dBi to test their products from 1995 to 2013. Below is a brief summary of our accomplishments during the 18 years we were in business.

From 1995 to 2001, under Don Bush's ownership and operation, dBi:

From 2002 to 2013, under John Barnes' ownership and operation, dBi:

Go to Main Web Site Index Go to Full Standards Index Go to ITE Standards Index Go to Residential/ Commercial Standards Index Go to Industrial Standards Index
Go to Lab Equipment Standards Index Go to Audio/ Video Equipment Standards Index Go to Lamps/ Luminaires Standards Index Go to Appliance Standards Index
Last revised December 19, 2010.