I’m not formally educated as an electronics engineer, though I am a software engineer. One of the things that happens with engineering is that you make mistakes. Because of this, I always design my first revision of a PCB for debugging.
This means that is has to be easy to test voltages, configure boot states and isolate the various functional blocs of the design. Things of particular interests could be; power supply, charge circuits, external peripherals (DAC, ADC, Shift registers, LCD, encoder etc) and whatever that’s new for you at the time.
Let’s dive into the few and simple techniques I use when I intentionally design for debug!
Make notes in your schematic
While you read datasheets and design your widget, you’ll obtain a lot of knowledge. Make sure it’s not lost in the ether, and make comments in your schematic as you go. This will save you time later. Trust me! If not, trust Robert Feranec!
Here’s an example where I did the calculations for a LiPO charge circuit, and did not want to repeat myself. Now, if I ever want to change the charge current, I’ll just refer to this comment (it also exposes a test point for checking thermal shutdown voltage range):
Test points
These are the bread and butter for quickly checking that you’ve not done big mistakes. They are useful for simply checking voltages with a digital multimeter. However, they are also excellent points for general access. Simply solder on some pins for hooking up an oscilloscope or a logic analyzer and you’ll be surveilling your design in no time.
HIGH/LOW pull selectors
One other thing that often surfaces is the need to be able to configure the default state of a pin for an IC. It can be anything from address selection to a boot state. If I’m not 100% sure what I want while designing, I add one of these for the first PCB spin:
Like you see here I usually make a guess as to what I want. If I’m wrong; I’ll just cut that tiny trace and add a solder blob between the signal (GND in this case) and whatever pull I actually wanted.
Functional block separation
Some times, when I implement a new technology and I feel insecure about my design – I add a series of 0R jumpers for completely excluding or including that block.
Most times, I’ll leave power out of it, and just use 0R on the signals going in and out of the system. This also exposes pads for me to access if I want to inject or read those signals with an external device. For instance I could inject a known serial signal, and look at the output using a logic analyzer.
0R jumpers for test access and block separation
Route out extra IO
This final tip can be very useful during the development phase for various reasons. Without dwelling on it too much I’ll just list them out and you can consider it for your own application.
- Signal various events with a pin change, for instance indicating sleep state
- Add and test extra/other peripherals (maybe you did need one more serial output?)
- Output or trigger self test states
