A new design is always a bit exciting. However much experience you have, even the best design checklist is no guarantee that something works as intended in the real world. What do you actually do with a first prototype once it is sitting on your desk, fresh from the factory (or hand-assembled)?
Preparation: half the work
The temptation is to get a new design out the door quickly and hook up the first prototypes right away to see 'if it works'. But how do you decide that, exactly? What do you want to measure? Thinking about that in advance is really helpful.
We write a test plan listing the measurements we intend to carry out as evidence that the design is sound. Once those measurements have been done, you get a clear bring-up report from us with all measured values and findings.
How extensive that needs to be is a judgement call per project. Scaling up to large series or complex products calls for more certainty than a simple breakout board. Ideally you write this plan before the PCB is ordered: that way you can place a few test pads strategically. A nice gold-plated test point is a lot easier to measure than fiddling with micrograbbers or soldering onto 0.5 mm pitch pins. Because the signal you want to measure is always that one track buried in an inner layer of the board...
The first test: smoke test?
The idea behind the smoke test is simple: connect the PCB to a power supply. Does your board go up in smoke? Then the test failed. Very clear, but also rather final.
There is a smarter way: we calculate the expected current consumption beforehand and set the supply with a very tight current limit. Or deliberately at too low a supply voltage.
That current limit does two things. It keeps a single mistake from being immediately destructive. But just as important: it quickly reveals deviations that would otherwise go unnoticed. A board drawing slightly more current than expected is not going up in smoke. Without current limiting you might only detect mistakes much later, while writing the firmware for instance. Or out in the field, once it's too late.
Usually this test just passes. Usually.
From practice: more than 25 mA...
I recently had a project where this very first test failed immediately. According to my calculations the idle consumption of this board should have been just 25 mA, while it was fused at 2 A. So, I tried it with a carefully chosen limit of 25 mA: no luck, straight into current limit. A short circuit? No, nothing obvious. With a bit more current the board seemed to work fine at first. All voltages were in spec, just fine.
Still, an alarm bell went off. Even though minimal power consumption is not the point in every design, a deviation like that is a sign. Either part of the design is not fully understood, or not quite right. The latter turned out to be the case.
Knowing something was wrong, I could track down the problem fairly quickly: by watching where a thin layer of cleaning alcohol evaporated it was obvious which area of the PCB was heating up. Measuring small voltage differences made the culprit clear: a TMUX1309A multiplexer. A fairly simple chip, what could possibly go wrong there? As it turns out, earlier in the design I was looking at the TMUX1109 or TMUX1209. All three have the same functionality, all three the same footprint. But the TMUX1309A has a completely different pinout.
And that is exactly why this did not surface in review: the TMUX1309A was in the BOM (as intended) and the assigned footprint was correct. But the schematic symbol assumed the pinout of the 1109/1209. It has since become an extra item on our design checklist. We are working on automating this kind of check in the future.
Fixing it was easy enough: order the 1109 and swap it. An afternoon of rework instead of waiting for a new PCB revision.
Of course we aim for first-time-right, but mistakes like this do slip through now and then. Which is precisely why that current limit is the first step in the test plan: the sooner issues like this are caught, the cheaper it is.
Validating power rails and sensor inputs
After a successful smoke test, the first thing we look at is the behaviour of the power rails: is the 3.3 V really 3.3 V, how much noise is on it and is that within the expected margins? Sometimes there are no hard specifications. Even in that case, at least thinking about what you expect beforehand (and adjusting that expectation if needed) is very educational.
Are there inputs for (analogue) sensors? Then we usually choose to connect a dummy. A known voltage source instead of a real sensor, for example. Or a network of known (precision) resistors instead of a PT1000 temperature sensor. Because what are you comparing your sensor against, really?
Fitting a 1000 ± 1 Ω resistor, equivalent to a PT1000 at 0 ± 0.26 °C gives you a lot more confidence in your measurement results than wondering how warm is my office today? about 25 °C sounds plausible?.
Another big advantage: this test is easy to repeat. As a QC tool during production, for instance.
Can't you just simulate that?
Some circuits (or parts of them) are well suited to simulation (which you can often do straight from KiCad!). Simulations help to validate a concept quickly or to fine-tune performance. But like design calculations, simulations remain limited by theory and by the assumptions you have to make. Reality is sometimes just a little more complex. And how satisfying is it to be able to verify your simulations with real measurement results!
Take this little pulse. A fast rising edge, a flat top, and then an exponentially decaying tail. What mattered to us was the rise time of about 1 µs. The simulation predicted exactly that, and it is exactly what we see back on the scope. The rest of the shape matches well too, especially given the expected tolerances. That builds confidence. Not just in this one pulse, but in the rest of the simulation model as well.
Firmware tests
Every board is different, but there is often firmware involved as well. We write hardware test firmware that exercises every important peripheral: do the onboard sensors behave as they should, are clock frequencies within the expected specifications? Once all the basic functions are up and running, certain tests can be repeated under load until we are willing to say: this board is validated.
The next steps? Depending on the application, further tests may follow. Think of extended burn-in tests and CE (pre-)compliance scans. Those often require further firmware development first, after which the product as a whole can be tested with its full functionality.
So what does a bringup report look like?
The best answer to that is an example.
View the anonymised example report (PDF, in Dutch)
This example report is based on a real report and gives a good impression of the test structure, pass criteria, measurements and findings as we carry them out in practice.
In closing
For us, board bringup is not a matter of switching it on and hoping it works. Our approach summarized:
- Decide up front what we are going to measure. A test plan with a clear pass-criterion for every measurement.
- Start carefully. Current limit tight, don't start running everything at maximum power. It's okay if mistakes cost a bit of time, but we don't want to waste a prototype.
- Measure against an expectation. Not 'looks about right', but testing measurements against a pre-defined tolerance. Start with dummies with repeatable behavior.
- Write down what comes out of it. A bringup report with measured values, findings and follow-up actions. Even when everything works first time.
What this gives you is proof that the board works. Along with the points that still need attention.
Developing new hardware and curious what such a test plan would look like for your product? Get in touch.