In-Circuit Testing: An Intern’s Guide
At the start of 2020 Simprints will be shipping 3000 of our new Vero 2.0 fingerprint scanners. This is more scanners than we have shipped since we started four years ago and we hope to ship more later in 2020.
Our scanners need to be robust enough to function in the often dusty, rugged, last-mile areas where front-line workers use our technology. Should any issue arise with any of the electronic components in the scanner, this could greatly impede the ability of front-line workers to deliver critical services. Replacing faulty scanners after they have been shipped is logistically challenging and cumbersome for our partners to have to deal with. To ensure each product is fully functional before shipping, our current Vero 1.0 scanners are tested at the time of manufacture, but this process is long and convoluted. So we have decided to make a new testing process for Vero 2.0 that will be fast and efficient.
Before I start I will quickly introduce myself. I am Archie, a Hardware Intern at Simprints. I joined at the start of the summer and was given the task of creating the Vero 2.0 test rig. This article will cover what I have learnt through my three months at Simprints, starting with an introduction into In-Circuit Testing systems, discuss the amount of testing a product needs and finishing with sharing the system we are developing at Simprints.
In-Circuit Testing 101
To enable us to test the scanners as quickly as possible, we are using a method called In-Circuit Testing (ICT). If you are not familiar with hardware manufacturing you probably won’t have come across ICT before but don’t despair, this article contains all the basics needed to get caught up. So let’s jump in.
In-Circuit Testing is a type of testing performed on the circuits of electronic devices before they have been assembled into their final product. Most circuits used in modern electronics are in the form of a Printed Circuit Board (PCB) which just contains all the connections needed for the circuit to work. Once they have been populated with components they are known as a Printed Circuit Board Assembly (PCBA). ICT is always done on PCBAs.
The most popular method of carrying out these tests is using a “bed of nails”. A bed of nails is an array of spring-loaded probes called pogo pins. When the Unit Under Test (UUT), which in most cases would be a PCBA, is pushed down on this array, sharp points on the pogo pins make secure connections with dedicated test points on the UUT. This allows for connections to be made quickly as there is no need for a locking mechanism. A further benefit is that no extra hardware is needed on the UUT as a typical test point is just a blob of solder. This saves money and board space on the PCB which is especially important in smaller designs (like ours). These beds of nails are typically built into a larger mechanism called a test fixture that also handles pushing the UUT down onto the bed.
The test fixture itself is just the mechanical component of the ICT system, while a separate component comprises the electronics around it. These electronics connect to the pogo pins and allow us to inject signals and power into the UUT while also letting us read signals being produced by the UUT. This allows us to ensure voltages are at the correct level, program microcontrollers, test components and many other operations. By combining a mixture of these operations you can ensure that the UUT is working the way it was intended and program the final production firmware onto the device before it goes to final assembly.
The final part of any ICT system is the software that runs the tests. This can range in complexity from basic firmware on an 8-bit microcontroller that just blinks an LED to show a device is working to a dedicated PC running multiple test scripts simultaneously and reporting to a server. It all depends on what product you are testing. The next section will talk about how you can decide what is needed for your system.
Determining The Scope
Before designing any part of an ICT system you need to decide the scope of your test. This can change based on the product and its application. At the lower end of the spectrum, tests will just check that the unit turns on, while at the upper end, they will make sure every trace on the circuit board is connected and that every component is within spec..
Of course you want to test as much as you can to ensure your product is robust, which is something we believe strongly here at Simprints (something our VP of Engineering talked about in our first blog post here), but there are trade-offs that have to be made. The more tests you want to do the more test points you need, which not only takes up board space, but also increases the complexity of the whole ICT system. There is also a labour cost involved as someone will have to be running the tests which can be the most expensive factor.
Not all products need to go through the rigor of ICT. For simple consumer products, testing may be more expensive than the product itself. Furthermore with the rise of cheaper and more powerful microcontrollers, self-testing can be a simple cost-effective solution for most. However, some products need to be tested to the extreme to ensure they will work in all contexts — especially if devices such as remote sensing equipment are used in locations where they would be difficult to fix or replace. We are near the middle of the spectrum at Simprints. Our fingerprint scanners are used for long periods of time in hot, humid environments and need to be robust and reliable to ensure that we can help our beneficiaries without any issues. However they don’t need to be bulletproof. If a scanner breaks, it can be replaced quickly and sent back to be refurbished if possible.
Our System
When creating our system we first had to choose what to test. We initially wanted to test everything, which would have required us to have two test points for every trace on the circuit board so we could make sure they were all there. However, this idea was short-lived after we calculated we would need over 500 test points, so we decided to cut it back. We went back to the drawing board and decided to focus on testing anything that could be affected by human error, like fitting the wrong resistor, or ordering slightly wrong components. We believe that these are the most likely types of errors to occur as all of the automated processes used to build the PCBA rarely go wrong and such errors would be picked up earlier. In addition to this, we will be testing the basic functionality of each chip on the PCBA as it will add very little overhead to our system. With this approach we ended up with 73 test points in total, the majority of which will be used to ensure that key voltages are where they should be and to enable us to communicate with the microcontrollers on the UUT.
Designed using the Autodesk Fusion 360, our system has three main components as mentioned above; a Raspberry Pi that acts as a control centre for the whole operation; a testing circuit comprised of an STM32, a battery simulator and some other analog circuitry, and finally a test fixture that contains our bed of nails. The system is controlled by a custom testing framework running on the Pi, written in Python, that runs all the tests, downloads the latest firmware binaries, programs the UUT and uploads the results to a server (We also get Slack notifications!).
The Raspberry Pi is the manager of the whole system and is connected to everything over a single USB cable. The cable feeds into an FTDI module that allows for three serial connections to be made. One for the STM32 that controls the test circuit, one for the Bluetooth module, and one for the UUTs microcontroller. Tests are run by sending instructions over these serial connections. We are also using the serial connection to upload firmware to the UUT, allowing for us to program temporary test firmware easily, which allows for more inclusive testing. During development of the Raspberry Pi testing framework I learnt a lot about how amazing working in a team can be, as I was able to work with my colleagues who have better Python skills to get the framework off the ground and fill in my gaps in knowledge.
The test circuit’s STM32 is what we are calling a dumb microcontroller, it doesn’t act on its own and will follow the commands of the Pi to control its peripherals such as a Digital to Analogue Converter (DAC, which allows it to set the battery simulator voltage), Analogue to Digital Converter (ADC, which allows it to read the voltage of the testpoint) and General Purpose Input Out (GPIO, which allows it to control the ICs on the UUT). Commands are also sent from the Raspberry Pi to the UUT to control its peripherals. This helped us reduce the complexity of system and reduce the number of test points. An example of the type of testing that will take place is to make sure none of the power rails of the UUT are connected to the ground rail as that would cause major damage to the UUT, and the ICT system. This test is done by sending a small current through the circuit and measuring the voltages at specific points. If the voltage is low that means we have found a short circuit and the device must be sent to us to allow for further testing.
An important feature of the testing circuit is the battery simulator based off of a TI App Note. It’s capable of sourcing the necessary current to power the UUT at the same range of voltages of a lithium polymer battery, while also able to sink current if the device is connected to a charger. By monitoring the current being sunk by the simulator, we are able to ensure the charging circuit is working correctly. This reduces the risk of battery issues that are associated with lithium batteries. This sits on a custom PCBA along with the STM32 microcontroller mentioned above.
Finally, the test fixture that will hold the bed of nails is a premade system that allowed the UUT to be pushed down onto a bed of nails linearly, as not to damage them, and be locked in place to allow the operator to run the test.Our original plan was to make our own fixture — but then we remembered we are a bunch of software and electronic engineers who don’t know anything about mechanical systems. The decision to outsource the creation of the test fixture was a big one to me as it made me realize that I don’t need to do everything by myself and support from other people is very valuable.
Final Words
Something you may have noticed is there aren’t any pictures of the whole system due to it still being in development. I am heading back to university to complete my third year as an electronics engineer. However I will be returning to Simprints at the end of the year and will hopefully be able to complete the final work on the test rig and provide a final update.
Before I finish off I want to share what I have learnt during my time at Simprints as it was my first internship at a company and working with others. One of the biggest things I learnt about is unknown unknowns which is how this three month internship turned into a team wide project for a couple of weeks and will involve me coming back to get it finished. This also shows the wonder of working with a team of great people, everyone was able to do something towards creating the end result. You also find out your biggest weaknesses when working with a team, which for me is planning, but they have your back and will help you improve yourself.
As an engineering student I learnt a lot about my field from my colleagues that you can’t really find elsewhere and isn’t taught at university. From different industry standards in PCB layout to how to write good clean production code. If any other students are reading this I would recommend internships as an opportunity to learn these skills and for an amazing experience.
I hope you have learnt something from this article, and hopefully I will be back soon with an update!
