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.
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.
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.
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.
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.
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: