Isn’t it great when you’re working on a making a tutorial, and in the process the whole reason for making the tutorial becomes very apparent? For instance; trying to set up a project like this (a 7 segment display decoding project) where the whole point is to analyze digital logic signals, and then the setup itself needs debugging.
Rat’s nest picture from here.
Following setup instructions can be awkward if the project presenter is really comfortable in their headspace and streamlines information that may not have been obvious to the reader. So, when following the setup in the linked project (which did turn out pretty cool), I had to modify code and circuits due to different parts availability (mostly, the project setup called for a common-cathode 7 segment display where I only had access to a common-anode 7 segment display).
My first issue was an error in the supplied code. Nothing crazy, just a little typo from transferring code examples from a book to a compiler or project post, and forgetting to change a variable name. Moving on, code compiles, program device. Then comes the fun problem, nothing displayed on the 7 segment display.
Now, my first step in troubleshooting is typical: grab a digital multimeter. It’s usually the first testing instrument we learn to use, it’s quick, and it’s easy. Metering the output pins from the FPGA gave an unstable value of around 1V. Okay, so there’s something happening, but how the hell would I know that it’s the correct thing happening? I don’t. Secondly, there’s more than one active pin and I can’t meter them all with a DMM. Plus, there’s still nothing on my display. Checking the base to emitter voltage on the transistors showed about 600mV, so they are presumably “on” somehow. So what is happening in between? To narrow my troubleshooting scope (pun intended), I needed to isolate the problem to the code or the analog circuitry.
To verify that I was getting logic signals from my FPGA, I needed a Logic Analyzer so I could see all of the logic step functions in real time. So, I set up my Digital Discovery, who’s high speed inputs allow the ability to correctly sample logic data (which becomes very important with digital signals operating at high clock speeds). Placing the digital scope on all the pins I was using on the FPGA, I verified that all pins on the FPGA were definitely sending signals. This was a great reduction in troubleshooting because I then knew the display problem was with the analog setup, and I could avoid doubting the code I was using (especially since I didn’t write it and it was supplied to be operational). I don’t know how many hours I have wasted looking through code for a problem that wasn’t there!
The original project design specified little buffer/driver circuits in series with the chip and the display as a form of power drive protection. The chip is not really built to drive higher power loads, and even though a few LEDs might not be a huge power load, the transistor buffer/driver was implemented as a “good habit.” Fair enough. However, since there was no signal passing through with this approach, I just bypassed that part of the circuit and finally saw a display!
But this is supposed to be a counter, with numbers displayed. Those segment arrangements don’t look like any numbers I have ever seen. So, I consult the Logic Analyzer again, but this time I’m not just verifying an output, I need to actually make sense out of the scope display.
Analyzing the signal busses and looking at the display, I realized that the logic signals were exactly inverted. Since the project was set up with a common-cathode display and I was using a common-anode display, the on/off driving of the LED segments were backwards. I was seeing the shapes for the numbers from the counter in the segments that were turned off, and the segments meant to be off were the illuminated segments. Inverting the binary assignments in the code fixed the problem, and the display project was working perfectly!
Moral of the story: use a scope, and the correct scope at that, when debugging your circuits. I should also look into my application of the buffer circuits. The original project design called for NPN BJT transistors, but to use PNPs if using a common anode display like I was, but apparently couldn’t figure out at the time. Please comment if you think you know what analog modifications need to happen for the common anode display. Thanks, and happy scoping!
4 Comments on “When are a Digital Multimeter and Analog Scope Not Enough?”
For a common anode display, I would connect each cathode to a current-limiting resistor, the other side of the resistor to the drain of an nFET, and the source of the nFET to ground. The gates could then be connected to the digital outputs, with a high output turning the segment on.
FETs are much easier to work with than bipolars for digital logic work, as they are voltage-controlled rather than current-controlled. You do need to use ones that have sufficiently low threshold voltages. If you are running a 5V system, the 2N7000 series is a good low-price choice. If you can use surface-mount parts, then something like the NX138AKR might be a good choice (good for 3.3V logic also).
Hi GasStationWithoutPumps! Thanks for the feedback. I get what you’re saying about using a FET over a BJT, that does sound more appropriate and easier to work with in this case. Next time I set something like this up I am going to do exactly what you’re suggesting. Much appreciated!
I would also recommend using FETs. The voltage at the gate electrode clearly controls current flow. Charge at the gate capacitor creates a depletion region under the gate. Thus, the current flows accordingly.
Thanks for reading. I am totally “on board” with the use of FETs for this application! Thanks for your input.