In our final installment of Tools of the Trade (with respect to circuit board assembly), we’ll look at how the circuit board is tested and programmed. At this point in the process, the board has been fully assembled with both through hole and surface mount components, and it needs to be verified before shipping or putting it inside an enclosure. We may have already handled some of the verification step in an earlier episode on inspection of the board, but this step is testing the final PCB. Depending on scale, budget, and complexity, there are all kinds of ways to skin this cat.
Hope
This is the least reliable method for PCB testing and verification, but basically it means once the board is done assembling, you do no testing and just assume it will work. Granted, some circuits are simple enough, and their assembly reliable enough, that this might work for a while, and the failure rate is acceptable enough without spending money on testing. Or maybe the product is cheap and you’re selling from China so if it arrives and it doesn’t work the consumer is going to be annoyed but not demand their money back. How many times have you bought something off Alibaba or eBay only to discover it didn’t work when it arrived? Yep, they probably used the “Hope” method of PCB testing.
Plug it in
Apply a power source. Does it turn on and blink? You’re good to go. This is the simplest form of functional testing and works on a simple circuit. Functional testing means applying an input and verifying the output. It may be great if the board has an easy power source and only one or two functions and no microcontroller or code that needs to be uploaded.
Test Jig
This is more complex than just plugging it in; in this case a special piece of hardware is designed that mates to the circuit board somehow and runs through some tests. If there is some kind of sensor on board, it may test that sensor and verify the output. As an example, a test jig for a smoke alarm could be a box filled with smoke. You put the battery in, drop it in the box, and see if it buzzes. A more complex jig might have pogo pins or servos that actuate switches or other ways of interacting with the board to verify that it works.
Programming
The methods described above are useful for cheap circuits and may be adequate. But many PCBs have microcontrollers, and that adds a whole level of difficulty because the microcontroller needs to be programmed, and the circuit will behave differently in different states. The test and programming jigs get a lot more interesting quickly. It should be noted that part of the complexity can be avoided entirely by having the chip manufacturer ship the chips with the firmware already on them. Most of the major manufacturers offer this service. This can be great for a couple reasons: it reduces assembly line complexity, it ensures that the chips are coming from a single trusted vendor and that there are no extra units being made in ghost shifts, and it prevents the factory from stealing the design or selling it to someone else, since they never get access to the firmware. There is a cost associated with this method, though, and it’s generally accepted that you don’t do this unless you’re in pretty substantial volumes and your firmware is locked down and won’t change. This is how the big boys do it. Below that, you have to program them yourself!
So how do you program your device? Well, it depends on the chip manufacturer. Atmel, Microchip, TI, Freescale; they all have their own preferred methods of programming, whether it’s the AVRISP, CC-Debugger, JTAG, or whatever. Most times there will be some kind of header interface, sometimes populated with a connector. It’s best if you can avoid the connector, as it will likely only be used once, is an extra component to populate, and takes up lots of board space. The better option is an edge connector or a pogo pin arrangement. The handy part about the pogo pin option over regular connectors is that you can just leave some bare pads on your PCB and use a special device with some spring pins that press against the PCB and upload the code.
The hardware for doing the programming is usually handled on a device by device basis. In some cases it’s possible to have a panel of PCBs (maybe 2×2) pressed down onto a large pogo pin bed and all of the PCBs are programmed at once, making this step quick. In other cases a jig for a single PCB handles the job. Often there is no record of firmware programming, and the programmer just blindly dumps the code onto the chip every time it is plugged in.
In my experience, I’ve built jigs that are pretty smart, and cost roughly $100. A raspberry pi or cheap android tablet runs it, a python script acts as the UI, and a custom 3D printed jig with pogo pins is the interface to the PCB, connecting through a CC-Debugger or AVRISP programmer. One feature that has been extremely helpful is logging; each device has a MAC address or unique ID, and in the course of programming the Python script grabs that ID and creates a record of what time, firmware version, and any other useful information. This record then gets added to our main device database, so that we can track and support a PCB from the moment it is first programmed.
It’s important to look at cycle time for this step. Every second adds up quickly, so the faster this step can be executed, the better. That means not compiling it every time (like programming from an Arduino). Programmers often have a verify step that is optional and makes sure the microcontroller gets the code, but takes 20 or more seconds. If you are successfully programming every device, do you really need to do the verify step? Later functional testing will show whether the code failed. Look for a cycle time on programming in the 10 seconds or less range. That’s why simultaneous programming can be appealing. Though it increases the cost of the programmer, it can significantly reduce the amount of time needed.
Functional Testing
Once the device is programmed, it is good to do additional testing on it. Generally, you can assume that the software doesn’t need to be tested on every device; it’s already been thoroughly tested in the lab and should work just fine (right? RIGHT?). What you want is to make sure that all of the features of the hardware execute the software correctly. Go through the PCB and develop a test that checks every block. First, check that the device powers up. If it doesn’t, there’s no need to test the rest of the PCB. Alert failure and why to the operator, and let them throw it in a rework bin for later. Next test that the microcontroller is functioning. Then have it communicate over the different ports it will be expected to use, like UART, USB, I2C, or others. Then have it interact with the sensors and verify that the sensors are returning values as expected. Flip all the outputs and verify that they work, and apply inputs and make sure that they are read correctly. Have it turn on whatever wireless components are on board and communicate with a device over wireless, and verify that it works. For every part of the circuit, there should be some test you can do to verify that it works, and you can get creative with your test jigs. If you can’t test it, you should question long and hard why it’s on the board in the first place.
In one project I had a sensor that had an LED and a photoresistor. During the testing, we put the device inside the test jig, which was a dark box, and measured the value of the photoresistor with the LED on and off. This way we verified that both components were working. While we could have put an LED and photoresistor on our test jig to verify the two components independently, this was an easy solution that reduced the hardware requirements and narrowed down any potential problems to one of two components that were both easy to debug if the test failed. This same box also played tones of various volumes to test and calibrate the microphone, checked the temperature and humidity sensor over I2C for reasonable values, connected to a ZigBee network, and did all this while talking to the tester over USB, effectively verifying every component of the hardware, and storing all the calibration values to a database, again tied to the MAC address of the device.
Boundary Scan Inspection, JTAG
Some of your fancier chips will have fancier capabilities for testing. BGA devices can be very difficult to test successfully. Boundary Scan Inspection is one of the ways to test these small chips through a single JTAG interface. It allows you to run tests which control at a much lower level the values of each pin. Only chips that are compatible with JTAG (IEEE 1149.1 compliant device) can be part of a boundary scan, because these chips have special pins which, when connected to JTAG override the core logic and expose their pins to the JTAG tests. By measuring the value on the other end of the trace, the Boundary Scan Inspection allows measurement of whether there are shorts, opens, testing some board components that aren’t 1149.1 compliant, and even verifying the existence of passives connected to the pins. If you are doing high megahertz processors, FPGAs, or expensive chips, or your board already uses JTAG for programming, then this method of testing might be for you.
Other types
We won’t cover X-Ray, AOI, or flying probe testing right now. These are all completely normal testing types for this stage of the process, but we already talked about them in the previous Tools of the Trade article on inspection. Manufacturers will handle the various testing methods at different points in the process based on the complexity of the board and specifications of the client.
Tips to make testing/programming easier
- Know how you are going to program the device and expose the connections you need so it’s easy to do. This could be a board edge connector, .1″ header, or bare pads for pogo pins, but plan for it during board layout.
- Have a plan for testing each component of the circuit.
- Collect data during the testing phase. You may need this down the line.
- Put your test points on one side of the board. Doing both sides is really difficult for a jig.
If you are interested in the other Tools of the Trade articles in the series, we have:
Tools of The Trade – Solder Paste Dispensing
Tools of the Trade – Component Placing
Tools of the Trade – Reflow
Tools of the Trade – Inspection
Tools of the Trade – Through Hole Assembly
Don’t forget about the horror of calibration!
Four important considerations:
– do you need to calibrate?
– do you [i]really[/i] need to calibrate? Maybe you should fork over for tighter-tolerance parts so you meet your accuracy requirements without calibration.
– Trim pots as they can be very fiddly and must be done by hand. If you’re only making a very few, or can charge a lot of money, that’s OK.
– Software calibration places a higher burden on the produciton software (e.g. you need to write Flash with calibration tables) but gives much higher cycle rates on the line.
How would one run tests on something analog, like say a guitar distortion effect? Easy enough to check if the power LED comes on, but how do you determine automatically (i.e. NOT using a human) that the circuit is working properly?
Well you’d wanna electronically characterize the desired output, and put a standard signal in that shows it. Even maybe using a custom signal that has an easy to detect effect when put through.
To test the guitar distort, a “Masked Pass/Fail-Tests” can be used. If the waveform is out of the black region surrounding the expected waveform, then the oscilloscope will trigger a fail signal,
https://www.youtube.com/watch?v=nd6WAXNuSY4
but usually testing is much more complicated then a mask test.
Of course, before start testing the hardware board, you need to design a whole test bench for your particular board. The test bench includes mechanical fixtures, power sources, signal generators, measurement instruments, computers that automate the test steps, and changes the instruments settings for each step. Also, you need precise specifications for accepted margins.
The end result of a test must be a PASS or FAIL verdict, and it needs to be accurate, fast and with minimal intervention from the test operator.
Do you always steal peoples work and not cite it? http://www.deepfreezefishing.com/programming-bluetipz/
LOL. That was me. I took those photos and I built that programmer, and those are my fingers in the shots.
My bad, I recognized those boards immediately because I helped build them. I had no idea anyone in eagle river Wisconsin played a role in hackaday articles, small world.
Pogo pins are awesome, but if you must use cables to interface between a test fixture and the device under test, use what I call “sacrificial cables”. Many times you’ll have internal cables inside a test fixture box which are annoying and time consuming to replace when it wears out or breaks. I’ve inherited test fixtures where the internal cables just come out of the test fixture and interface directly into the “DUT”. It really sucks when they need to be replaced.
Connectors are only rated for so many insertion cycles before crapping out. It’s better to have the internal cables terminate in panel mount connectors mounted to the enclosure. Then an external sacrificial cable can be designed to connect to the panel mounted connector. The sacrificial cables can be made in small batches, so when one wears out or breaks, it is extremely easy to swap out. More importantly, production only has a minor interruption while a sacrificial cable is swapped out, instead of needing to partially disassemble the whole damn test fixture, just to replace a cable that wasn’t well thought out during test fixture design.
YES! I’ve seen a few of those .1″ or .05″ header connectors wear off where the ribbon connects to the connector; at first it’ll just be a spotty connection with no explanation, then you’ll realize you have to hold it a certain way for it to work, then it’ll get harder and harder to hold it just the special way, and then you get frustrated and swap out the cable. Best if the cable is easy to change.
I think you touched on this, but one useful approach for microcontrollers is to have a test mode, triggered by a discrete. Then you can test gpios and ports, without worrying about normal operation state.
A separate test mode is great! In a product design at my day job, rather than a discrete / testmode pin, there’s a separate FW build that just does testmode. Since we use the jig to both flash & test, we can just have it flash the test FW, run the test and then flash on the ‘real’ FW. Also very helpful for testing of complex devices: good collusion between the jig and test FW. In the test FW, the SWD programming pins are used as GPIO for signaling between the two, so the DUT and jig host are on the same page about which test is being run. This lets the jig set up stimulus signals appropriate to the test, e.g. simulating high/low sensor inputs, full/discharged battery, etc.
Merifix, http://www.merifix.com
Makes a cool, affordable kit of clamshell type pogo pin fixtures.
In fact you upload a excel coordinate file and they will print a check plot and drill the test bed for you.
its like 300-400 dollars.
cool link, thanks!
I’d love a write up on the boundary scan style JTAG testing. I remember reading about it at a previous job and thought it sounded intriguing, but the microcontroller we used at the time didn’t support it so I gave up on that. I’ve yet to encounter an employer who utilizes that for testing, so I’m not sure how common it is.
I strongly disagree with skipping the verify step after programming the firmware. Functional testing should prove that every microprocessor input can be read and every output should be driven to all valid states. Skipping the verify step means that each path through the code must be verified, and that can take far more time (exponential?) to arrange, especially if timers are involved. (Yes, you can provide a ‘speed-up’ pin, but then that, too, must be tested for correct operation).
A further belt-and-braces test would be for the microprocessor to checksum its program and refuse to run if the value was incorrect. Not all processors that I have used would have been able to access all their program memory space to perform this test, however.