Almost every product designed is required to pass a suite of tests
known as Electromagnetic Compatibility (EMC)
tests. The suite of EMC tests usually includes some form of each of the
following: electro-static discharge (ESD),
radiated emissions, conducted emissions, radiated susceptibility, and
conducted susceptibility.
There are many versions of each of these types of tests. The version
that applies to your product depends on the products application and
the agency approvals (UL, CSA, EC, etc.) that are required. A common
misconception is that EMC issues are the domain of hardware engineers,
when in reality an embedded software engineer can and must be involved!
This article will cover many of the basics for how a software
engineer can provide help with product EMC performance and testing. But
it is certainly by no means an exhaustive list. Many times a little bit
of thinking outside of the box can provide the solution to a pesky EMC
problem. So don't be afraid to try things!
Typically, there are at least four ways the embedded software
engineer can aid in the process (order of value added):
* improve performance against susceptibility tests,
* provide debug assistance for susceptibility tests,
* provide automated execution of device functionality, and
* minimize emissions.
Improving Performance against
Susceptibility to EMI
First, let's address how an Embedded software engineer would be
involved in dealing with the device's susceptibility to Electromagnetic
Interference (EMI). The hardware engineer's role is to prevent as much
EMI as possible from ever reaching the product's sensitive electronics.
However, sometimes it's impractical for this to be accomplished well
enough to pass all tests. Using software techniques to resolve issues
with susceptibility to EMI can be quite beneficial because software can
almost always remain fluid much later in a product development cycle
than hardware can. When a troublesome susceptibility issue is
discovered, it quite often would cause significant schedule pain to
perform another round of hardware changes.
On the other hand, software is much more likely to be able to absorb
the time required to implement solutions. The Embedded software
engineer provides the second line of defense. His role is to minimize
the disruption to the product caused by EMI that has gotten past the
Hardware Engineer's first line of defenses.
Sometimes a passive filtering solution to an EMI susceptibility
issue is technically not a challenge to implement, but might be
problematic when a small board size is desired. Adding capacitors and
ferrite beads can consume valuable board real estate! If a solution can
be implemented in software, there is no negative impact on the board
size, making it the preferred solution.
Mechanisms are put in place that increases how well the system can
tolerate the residual EMI. The residual EMI can adversely affect the
system in many ways. It could corrupt:
* microcontroller registers,
* memories,
* communications channels,
* digital I/O, and/or
* analog I/O.
Corruption of microcontroller registers can manifest itself in many
different ways. If the program counter is corrupted, the program can
execute code out of sequence, or execute from an unprogrammed location
in the program memory.
Using watchdog timers
Probably the most time-tested method of verifying flow control of a
program is through the use of a watchdog timer. A watchdog is a
free-running timer that when expired causes the reset of the
microcontroller and/or system. The expiration of the timer is avoided
by resetting the timers count value through some simple maintenance
method.
Usually this maintenance is as simple as providing a pulse on an
input to an external watchdog chip or providing a specific write
sequence to an on-chip watchdog register. The maintenance of the
watchdog is added at key points in the program.
If the execution of the program goes haywire, the watchdog will not
be properly maintained and the system will be reset. Watchdog
maintenance must be properly designed however. If the maintenance of
the watchdog is placed in a timer ISR, then the maintenance may occur
properly even though the foreground execution is lost.
A more acceptable design technique would be to set the output high
in the foreground routine, and low in a timer interrupt service routine
(ISR). In this case both elements are required for proper maintenance
of the watchdog. The benefit is that some noise event might disrupt
execution of the device, but instead of ending up in an unknown state
or possibly even trapped in an endless loop, the device resets and
resumes functioning.
Another method of program flow verification is to use sequence
checks interspersed throughout the program. A sequence variable is used
to verify the program sequence. At select points, this variable is
compared against an expected value. If the value is correct, it is
incremented (or somehow set to its next expected value). If the value
is not correct, the controller can go to an error state, or invoke a
software reset of the controller.
It should be noted that this method adds overhead to the program,
and is not easy to maintain, especially when changes to the program
flow are required. This method is usually only advisable in
safety-critical systems where execution out of sequence can have
hazardous effects.
