Software techniques for comprehensive EMC testing of embedded systems
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.
Loading comments... Write a comment