The Inexpensive Way to Address EMC Issues
n more than ten years working in labs as an EMC engineer, the majority of devices and systems I have tested include two important elements that interact with each other, thereby allowing the equipment under test to work. Electronic boards and firmware. It is difficult to imagine an electronic board without firmware running in a microcontroller. Even a simple wall charger for batteries has integrated firmware to switch the behavior of the charger from constant voltage to constant current, and to switch into trickle charging or to begin the discharge process.
Over the years, I’ve come to think of firmware as the soul of every electronics board since, without firmware, almost every PCB would be “dead.” But because firmware is now so deeply embedded into the working mode of a device, what is the influence, if any, on a device’s EMC performances? Could, in theory, at least, a device using different firmware versions behave differently during EMC measurements? We’ll explore that question in this article.
During my daily time in our testing laboratory, I often feel the pressure faced by the electronics designer, who is deeply involved in matters like costs and budgets. As a result, EMC measurements should be taken into account inside the budget analysis of a project. As an example, a full compliance EMC measurement evaluation of a medical device with a power cable, one I/O cable, and radiating emissions up to 6GHz could result in an expenditure of thousands of Euros, even if the equipment under test (EUT) meets every testing criteria.
According to what I have written above, the great advantage of taking the “firmware approach” is the cost and speed of implementing the solution. So it might be useful here to provide examples of common solutions involving firmware changes. Of course, the list is far from being complete, but I think it represents a good starting point.
Figure 1 shows an example of a de-bounce algorithm based on a timer and interrupt method. A firmware engineer can implement different techniques, depending on the final application and the object of the de-bounce (capacitive touch control, mechanical switch, and so on).
Another technique used to avoid spurious data is averaging. It is used mainly when slow phenomena have to be acquired by sampling a huge amount of data, for example, environmental parameters like temperatures, humidity, etc. In case the injection of a disturbance during immunity tests (both conducted and radiated) alter some data, the averaging keeps the trend stable by reducing unwanted variations.
After some tests (e.g., disconnect cables, switch off one module after the other, etc.), we managed to spot the issue. On one 3 meter length cable, two signals were present: 1) an SPI to read from an ADC; and 2) a serial communication for the link between the two microcontrollers (115200 baud). The datasheet for the microcontrollers noted that, in cases where the PINs are configured as outputs, a speed selection command was available. This command was not set but by default, the compiler set the speed at its maximum rate. By slowing down the two speeds maintaining the overall performance and stability of the system, the problem was solved without adding a single capacitor or ferrite bead to the board (see Figure 2b).
A customer brought in the laboratory a system (an access control system for home use) with a capacitive keypad. During testing, we discovered issues with conducted immunity levels, in which the system was taking unwanted commands when a disturbance was applied. Overcoming this issue was as simple as changing the configuration of the capacitive controller by modifying a few lines of code. This modification solved the problem.
Q. Who are the most suitable people to assist during the measurements?
A. Electronics engineers and electronic designers with deep knowledge of the board under test, and software engineers who developed the firmware (in some cases, these two are the same person).
Q. If the firmware of a product is changed/updated, do EMC measurements need to be repeated?
A. It depends on the modifications implemented in the firmware. The firmware is very often connected to the results of EMC tests, both for immunity and emission. Taking that into account, it’s unlikely that testing two samples of the same equipment loaded and running with different firmware will produce the same test results. Would you take the risk?
I confess that it was hard to find resources for this article, which is mainly based on my experience and daily laboratory life. However, here is a short list of resources where the reader can find some hints and further suggestions on firmware-related issues.
In addition, I would like to give the reader some thoughts about the reactions this article generated on social networks, with some suggestions and hints received from readers and commenters.
Two other ways of solving EMC issues during measurement campaigns using firmware-related techniques are spread spectrum and data scrambling. The first is very well known and often implemented, for example, in switch-mode power supplies (SMPSs), sometimes in a transparent way to the designer. The latter is related to the way of transmitting high data rate digital information. Its purpose is to smooth out the spectrum of the transmitted data from peaks and spikes by acting on the bit sequences in order to resemble the spectrum of white noise instead of the one produced by data transfer. For the curious reader, the last reference is about these two techniques.
- In Compliance Magazine. (2018, December 7). “What Every Electronics Engineer Needs to Know About EMC Chambers.”
- Tim Williams, EMC for Product Designers (fifth edition), Newnes, 2017.
- Keith Armstrong, EMC for Printed Circuit Boards (second edition), Nutwood UK Limited 2010.
- Keith Armstrong, EMC Design Techniques, Nutwood UK Limited, 2010.
- Clemens Valens, “How to Debounce a Mechanical Contact or Switch,” https://www.elektormagazine.com/news/how-to-debounce-a-mechanical-contact-or-switch/21422.
- Some examples of debounce code, http://www.emcu.it/STM32/STM32Discovery-Debounce/STM32Discovery-InputWithDebounce_Output_UART_SPI_SysTick.html. The example shown in the article is taken from this website.
- Henry W. Ott, Electromagnetic Compatibility Engineering, Wiley 2009: chapter 15.10.
- Keith Armstrong, Suppressing Emissions by Using Data Scrambling and Spread Spectrum Hardware Design Techniques, https://www.emcstandards.co.uk/files/suppressing_emissions_using_data_scrambling__spread-spectrum_techniques_november_2013.pdf.