Before Commissioning an Embedded System, Implement These Test Cases
Dating someone who loves shopping and obsesses over tiny details like thread count means making countless trips back to the store for exchanges and returns based on microscopic defects. Not surprisingly, I often grumble about the amount of time and money spent traveling to complain about minor defects that no one would likely even notice.
Of course, while I can’t understand the need to obsess over perfection in clothing, I do understand the importance of thoroughly inspecting and testing a newly developed embedded system before commissioning it with the client. Complacency in testing can hit you hard and at the moments you would least expect. For this reason, it is crucial to implement particular test cases before commissioning an embedded system.
What Happens When You Fail to Conduct Rigorous Testing
If you fail to conduct rigorous testing in a timely manner, your embedded system PCB could end up in smoke or be a dysfunctional mess. Simply ensuring that your hardware passes basic testing may not be enough. However, some test cases can push hardware to the limits that the human mind may not be able to foresee. Such rigorous tests can, if objectively implemented with improvements in mind, can minimize significant hurdles down the road.
If test cases are ignored, however, problems can pop up. Seemingly random, these problems can be awfully challenging to troubleshoot. Without test cases beforehand, it can be nearly impossible to solve problems like a flash memory database becoming corrupted every fortnight or embedded system that regularly freeze on hot afternoons.
As most problems typically creep up while the embedded systems are being deployed, troubleshooting becomes virtually impossible as the systems are often reset before you arrive onsite. What’s even more frustrating is when you fail to replicate the erroneous symptoms at your lab.
How to Test Your Embedded System to its Limits
Having dealt with my fair share of issues after taking my design for granted, I’ve learned my lessons. Now, I ensure that each of my embedded systems is tested for these conditions:
1. Database Records Boundary Test
It’s for an embedded system to be used in data logging applications. This usually involves storing hundreds of thousands of records and supporting online retrieval. It’s also for applications to retain records securely in offline mode. In some cases, like a payment machine, missing records can cause major massive problems for clients.
There is no excuse for not pushing the limits of your embedded system’s data storing capability during the development stage. Prepare for unforeseen circumstances by examining what happens to your embedded system when the database is full or overlapping with the memory starting address.
Boundary condition is a failure point for embedded systems.
2. Operating Temperature Limits
When you’re designing embedded systems for usage at room temperature, skipping temperature limits testing may not cause any repercussions. But if you’re designing for the outdoors or any high-temperature environments, trusting datasheets and skipping testing may induce a high risk of hardware failure.
One of my worst experiences with skipping temperature testing was when a newly launched microcontroller halted before it even reached its maximum temperature limit. Of course, this called for a costly recall and complete hardware revision using another microcontroller. I learned a valuable lesson at that time: to be safe, test your embedded system in an oven if you have to.
3. Maximum Operating Current
It’s practically an unforgivable sin if you neglect to test your embedded system in conditions where it operates at its maximum calculated current capacity. Being human, engineers are fully capable of occasionally making mistakes; the same is true for chip manufacturers. Use an ammeter to measure the total current and ensure it doesn’t exceed your calculated limit.
I once made the mistake of routing a smaller track that became overheated when hundreds of LED were turned on simultaneously. While the deep-sleep power savings mode can be handy, testing your hardware to its maximum current capacity ensures that it remains relevant when the nature of application changes.
Is your embedded system still functional when it’s fully loaded?
If you want a good idea of the current densities of traces before fabricating your PCB, you can also use Altium Designer®’s PDN Analyzer™ . This greatly decreases the possibility of issues caused by operating the hardware at its peak current capacity.
Are unexpected problems plaguing your embedded systems? If you’ve missed any important test or simply want to maximize the integrity of your system in any environment, chat with an expert at Altium.