Introduction
The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions.  We hope you enjoy it.  If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to[email protected].
Did you plug it in?
Late last week I delivered a rather complicated board I had been working on to one of my customers.  During the demo, we discovered that one of the regulated voltages was not getting to the part of the board we wanted it to get to. Don’t you just hate it when your work fails right in front of a customer? This was the second board we built and the first one worked fine, so we knew it was not the design.  I took it back to the lab to find out the cause.
This got me thinking about debugging techniques.  Debugging is all about asking the right questions.  As a teenager, I remember complaining that some electronic gizmo was not working and I did not understand why.  My father asked me if it was plugged in.  And that is a very good place to start.

Look for a puddle of electrons
Tip #1: Measure the voltage to the sub-circuit of interest. The voltage will tell you a great deal.  For example, if it is not present that tell you something totally different from its there, but I’m putting in 10V and only seeing 3.7 volts.  If there is no voltage, you will want to see if the power supply is plugged in. Is there a fuse blown? Think of your circuit as a river of electrons, if you have no pressure there must be a ‘leak’ somewhere. Where does the circuit deviate from what I expect to something that surprises me?
We recently powered up a board and had initial success, all the voltage levels looked good.  Then we added additional functionality and all of a sudden, the voltage levels dropped dramatically.  We were applying the correct voltage but it was being pulled down to a fraction of the desired level.  This is called crowbarring.  We had limited the current to a low level (50mA) to protect the circuit if there was a short.  That worked at first (a draw of 40mA did not affect the voltage) but the additional functionality drove the current consumption to higher levels (well above our 50mA limit).  We raised the current limit and the circuit performed as desired.  This is a judgement call.  If there is a short, it will pull the voltage down as will a higher current draw circuit.  The difference is the way it crowbars.  If it is a short then the voltage will not raise much as you increase the current limit.  With a high draw circuit, the voltage will rise when you increase the current limit.
Two more tips: Tip #2: On a new board, it’s worth checking the resistance of the board before power on.  If you read 1 or 2 ohms on the input power or any of the regulated voltages you’re likely going to have an issue.  Tip #3: Use a power supply to limit the current to the board.  This will let you evaluate things before letting out that precious smoke.

Well, that’s a horse of a different color
When debugging, you will use different techniques on a new board than you will on a piece of equipment that has been working for years and suddenly stops.  The questions you ask compare the way you expect the device to work with the way it actually works.  In your head, you have, or should have, a model of how you expect the circuit to work.  Troubleshooting is all about comparing the model to the real world and evaluating the differences.  Tip #4: Make a mental model of the device in your head.
I once asked a person in a parking lot, who was having car problems, if I could help.  They said their car would not start.  I then asked what it was doing.  They looked at me like I was crazy, “I just said it won’t start.”  Right, but does the engine turn over when you turn the key? Does it crank but not try to start? Does it start and then die right away?  The problem was their model was too simple. You turn the key and the car starts.  It didn’t do that, so they were done.
When I worked in a chemical processing plant, I leaned to think about the process at each stage and how what was going on at the point in the process I was observing could affect the plant, or the processes, downstream.  A circuit board has a more in common with a chemical processing plant than you would think.  Tip #5Understand how each sub-circuit affects the subsequent circuits.

The right tools for the job
When I got the demo board back to the lab, I pulled out a schematic and the board layout and tried to find a place where things were working the way I expected them to work.  A schematic is an essential tool.  Having a board layout is great, but not something we always have available.  I found that I had main power and all the regulated voltages looked good at the sources.  Still I did not have voltage at the output like I wanted.  I worked from the regulator toward the output connector and encountered a switch.  The switch selected the source of the voltage at the output connector.  It was in the wrong position.  I flipped the switch to the other position and it worked as desired.  The easiest of all fixes.
Getting that board working involved understanding how the circuit worked, using the right tools and going back to the beginning, making sure it was plugged in.
Tip #6: Evaluate the clues.  Look at what the circuit is doing, when it is doing it and try to evaluate why it is doing such an inconvenient thing.  Unless you are working on an Infinite Improbability Drive the clues will lead you to the correct answer.
I hope these tips help you in your debugging efforts.  Why not send me a quick note and tell me one of your favorite debugging techniques.  And FYI, Tip #7:Tequila is not a debugging technique.

Final thoughts
This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan, Utah, which can be found on the web at:www.celticengineeringsolutions.com.  You can find the newsletter on the company blog, LinkedIn or by subscribing.  Send your emails to The Celtic Engineer at:  [email protected].