Month: January 2019

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! Original Project Posting Updated Project Posting

Month: January 2019

How To Use The Scope Filter Channel

Introducing the Pmod AQS… A New Air Quality Sensor

OpenLogger is Funded!

How to Plot the Frequency Response of a Circuit

Pushing the Envelope Detector: Exploring Demodulation, AM, and FM signals.

Smart Workspaces With The Analog Discovery 2

Which Cable(s) Do I Need?

Exploring GPS Systems with the PmodGPS

When are a Digital Multimeter and Analog Scope Not Enough?

Hidden

Recent Articles

Introducing the Analog Discovery Pro ADP5250: The Biggest, Baddest, and Boldest Analog Discovery Yet

Six Ways VAXEL ZERO Benefits FPGA Engineers

Constraining Ports Manually via XDC File vs. Board Files

Is Remote Learning Here to Stay?

Company

News

Affiliations

Subscribe to our newsletter

Hidden

Contact Us

Be the first to know.

Hidden

Recent Articles

Subscribe to our newsletter

Hidden

Contact Us

Be the first
to know.