How do you attack a new board?

Question

You get your PCB back from the manufacturer. It is a new design, you have of course bread-boarded all the major parts, but you know there are going to be problems. There are just too many things that can cause problems, e.g.:

• Errors in the schematic
• Errors in the layout, not found by the ERC/DRC
• Misplaced parts during soldering
• Shorts and the like during soldering
• any combination of the above

I've had two relatively complex boards lately where I've basically had to de-populate the entire boards after assembly in order to locate the error. I found the errors, but the boards were scrap.

I've tried to start with the bare minimum of parts and the parts that can't be hand-soldered (I'm using paste, stencil and toaster). Typically this would be the MCU, the JTAG connector and a few capacitors. Then I'm gradually populating other areas while checking them for problems.

This approach works, but is really slow. I also have to comment out/comment in any code that assumes the presence of some particular hardware.

Does anyone have tips/suggestions on how to approach newly designed PCBs?

EDIT: I'm mainly thinking about the kind of problems that leaves your board dead, like hidden power rail shorts, or anything that bricks the MCU.

Answer 1

I've decided that breadboarding ahead of time is a waste of time unless there are aspects of a part's performance that you need to measure yourself.

I even think building the board in pieces is a waste of time. The initial hardware debug just takes a day or two. Any subtle issues won't show up until software integration anyway. I'd rather debug one circuit (the complete one) than several ad-hoc reductions of the circuit.

Just build the thing! Assemble the whole board and power it up. Look at the supply voltage. How many mA does it draw? Which part is burning hot? Which part is warm? Then try to burn firmware on to whatever microcontroller is on the board. Then start writing firmware. Get the clock going and toggle a pin. Get serial (or whatever) communication up. Now write test programs for each peripheral. Then build the production test fixture and start writing the "real" firmware.

---

Edit:

On finding stuck rails

If a supply rail is stuck to ground, (measures 0 ohms with an ohmmeter), power it up on a bench supply. Set the voltage normally and the current limit to a few hundred mA. Print out the PCB design on paper, and find a DMM that measures microvolts. Measure microvolts starting at the supply terminals, and write down the voltage drops on the PCB printout. By looking at microvolt differences, you can trace exactly where the current is going without depopulating or chopping up the PCB. This technique is a better than using an ohmmeter because you can pump a lot of current through the circuit, more than any normal ohmmeter will supply.

A similar technique works for finding shorted traces on an otherwise populated board. Run the board a use a scope to find "digital" traces that are in an in-between voltage range.

Answer 2

I do it by populating the board with the bare minimum initially, getting the supply working first, then the MCU, then adding the various sub-systems one at a time, and testing them before continuing, writing test software as necessary. I don't find the process at all slow.

I have boards of any complexity bare-board tested. It costs extra but it's worth it.

Answer 3

I only breadboard very small circuits. Then I solder the small circuits onto proto-boards. If working with SMD chips, it helps to get the SMD->Thru-hole adapters.

This basically gives you "building blocks". I then solder these circuit blocks onto a dev kit, or an old PCB with the MCU that I'm trying to use. It looks atrocious, with four or five different small PCBs hanging off of a larger one, but it works.

Once I have the building blocks working on a dev board, I move to a PCB. If the schematic changes at all while making the PCB, I go back and rework the building blocks and test them on the dev board again.

---

On a side note, instead of commenting out code, you should look into using #define and #ifdef preprocessor directives. It makes it significantly easier to add and remove functional blocks of code in an MCU.

Answer 4

With boards of any complexity, it's nearly as important to develop a test plan as it is to develop the board itself. Even at the outset of designing the board, it's a good idea to know what you will test, even though the implementation doesn't exist yet; "design for test" as they say. Be sure to bring key signals to test-point pads. Try to partition the design so that individual subsystems can be brought up independently, or as nearly as independently as possible.

Answer 5

I suppose one key question is: What is the pre-flight checklist before you release a board to production. My pre-flight list is:

1. Schematic design review
   1. Net names and off-sheet ports
   2. Power supply pins connected
2. Schematic DRC
3. Footprint scrub
   1. Complete manufacturer part number
   2. Part number matches footprint on PCB and pinout in schematic
   3. Footprint pin number is "right-side-up" and correct
   4. Footprint dimensions double checked for hole sizes, clearance, keepouts, etc.
   5. Mating connectors are oriented correctly; pins 1-to-1, 2-to-2, etc.
4. PCB Dimensions and holes
5. PCB DRC
6. Fab Drawings has all layers and call outs.

This answer community wiki'd.

Answer 6

What the other guys said is all valid, but I'd like to add my 2 cents worth.

The absolute best thing to do is not make the mistakes in the first place. It seems silly to mention this, but all too often this is overlooked. Do a schematic and PCB design review. Have several people look at your design-- even beginner engineers. Use the design rule checks in your software. Use any resource available to make sure your design is good. Have good engineering practices to improve your odds of catching a bug.

In the past 20 years, and having designed dozens and dozens of PCB's (some with 14 layers and 2,000 components) I have only had TWO pcb's that were unusable on the first round of prototypes. Of course I've had bugs, but only two boards were "bricked".

In every case, the prototypes were fully populated before I ever started debugging them. I'd ohm out the power rails to make sure there were no shorts. Then do a visual inspection using a microscope. Then power it up. After that I'd start on a methodical test and debug session-- working on small sections of the circuit at a time until everything is tested and working. In most cases, I'd make a couple of changes and go into volume production with the next revision of the PCB.

None of this would have been possible without major efforts to reduce the bugs up front.

Answer 7

On a totally fresh design, I generally go with a divide-and-conquer approach.

I try and isolate major architectural blocks and power up each section independently using switches / DC supplies / potentiometers etc. to simulate the dependencies needed to get the circuit to run.

This approach generally isn't hard when you're dealing with power supplies - most converters need only input and perhaps a few logic signals to start switching away (and hopefully not releasing the magic smoke of failure).

Boards that are second/third spins (clean-ups) don't usually need such diligence. I may only isolate parts of the circuit that were changed, test them independently and save testing the rest of the circuitry for the all-in power up.

Don't forget your personal protective equipment. I'm very uncomfortable powering anything with exposed components up without my safety goggles (and sometimes earplugs...)

Answer 8

Well, one of the first steps to prevent shorted nets from happening in the first place is to make good use of the design rule checks in your board software. Both at the schematic level to make sure nets aren't inadvertently tied together when they shouldn't be; and at the PCB level to make sure sufficient clearances between nets.

If there are any design elements that are untested, rather than tackling a whole new design on one board, I try to build proof-of-concept and proof-of-performance test boards on cheap proto PCB's (like Advanced Circuit's BareBonesPCB service - two layers, no solder mask, about $80 for a 24 hour turn).

Even when I do a complete board, on the first generation boards, I like putting in plenty of breakout headers. In some cases, you can populate two identical PCB's, one with the "stable" portion, with header pins exiting to the top; and another with the "testing" portion, with bottom entry pin receptacles. If everything tests ok, you can then finish populating both boards. Or, you can spin new versions of the "testing" circuit that you can swap into place.