Providing Debug Assistance
When running formal EMC tests, the test setup must be non-intrusive. In most cases, it is not acceptable to connect an emulator to the unit under test, or to connect an oscilloscope probe to the unit under test. The emulator or scope could influence the EMC test results. When the applied EMI causes the unit to fail, it can be very difficult to determine in what way the unit failed.

The embedded software engineer must provide as much debug assistance as possible to reveal what the failure mechanism was. Sometimes the required debug assistance can be quite simple. A highly effective yet simple method is to provide some type of dynamic signal that indicates that the unit is "alive".

An LED, for instance, can work well for this purpose. If this dynamic signal can be changed (in frequency for instance) when the unit has entered an error state then the signal is even more effective. Usually more debug assistance is required though.

When running burst, surge, or ESD testing, real-time status of the unit can be monitored through a wireless communications link (IrDA, 802.11, Bluetooth, etc) if one is available.

If no wireless communications link is available, or when running radiated susceptibility testing in an RF anechoic chamber, you might have no choice but to debug the unit "after the fact". Detailed non-volatile logging of pertinent events can provide valuable clues as to what happened.

If there are communications links, even on board I2C, CAN, or SPI busses, keeping performance statistics that can be queried after the test suite has completed can also indicate a problem area that otherwise might not have been observable. Non-volatile event and statistics logging is preferred since the EMI could lead to a system reset.

If non-volatile storage isn't available, it still might be possible to query statistics, device state, and other pertinent data from the device if it remains running in the failure state after the test suite completes. It may be possible to deduce the method of failure by seeing the result of the failure.

It's quite typical that informal prescreening tests are run prior to executing the formal EMC test suite at a test house. Use this opportunity to find the suspect areas and determine what data needs to be accessible during or after the test. It might reveal previously unforeseen hot spots that require some creative means of providing the clues to the source of the problem.