Radiocommunications Agency  EMC Awareness

Software immunity

What this technique is used for

Hardware techniques are not the only method for improving the electromagnetic immunity of digital products. Software also has a part to play. Standard techniques of error checking and correction, and data validation, should be used wherever possible. Over and above this, there are certain other approaches which software designers can employ. The most important point to remember is that hardware does not always do what the software has programmed it to do: interference can make it behave differently, and a good software design will take this into account and be able to catch errors before they cause serious effects on the equipment operation.

How this technique is used

The techniques used within the software fall under a range of headings:

• type-check and range-check all input data: set known limits on the values that enter as digital input to the software and reject anything that lies outside those limits

• sample input data several times and either average it, for analogue data, or validate it, for digital data: using a reasonably fast polling rate for logic inputs and ignoring data until it has settled will make digital inputs blind to fast transient bursts or surges

• incorporate parity checking and data checksums in all data transmission

• protect data blocks in volatile memory with error detecting and correcting algorithms, for instance checksums on critical data tables; implement write locking on non-volatile memory, and use a COPY-MODIFY-STORE-ERASE sequence to prevent critical data from being corrupted if the processor crashes in the middle of a write sequence

• wherever possible rely on level- rather than edge-triggered interrupts, since these will be less sensitive to transient noise and ESD; monitor the stack pointer for overflow, as a burst of noise on an interrupt input could cause such an occurrence

• periodically re-initialize programmable interface devices, especially I/O port registers – don’t assume that a programmable device, once programmed, always stays that way

• incorporate token passing in subroutine calls, so that critical subroutines can check the authority of the calling routine

• fill unused program memory with instructions which will cause a predictable sequence of events if they are accessed in error

• implement a watchdog: if the processor crashes after all the above precautions are taken, this will at least arrange that it restarts gracefully.

Key issues in employing this technique

Some means of disabling many of the above software error-checking routines is necessary when you are testing equipment against interference, as otherwise the true performance of the hardware design cannot be assessed.

Not all microprocessor faults are due to interference. Other sources are intermittent connections, marginal hardware design, software bugs, meta-stability of asynchronous circuits, and so forth.