Advice on Testing TTL Signals

[Yngbld]

Hey guys:

Long time listener first time caller!

I've been playing around with arcade boards for awhile now and have had a few wins under my belt. Essentially I've been probing boards with a logic probe testing signal activity measuring VCC voltages, verifying roms and testing suspect TTL's with various eprom programmers and to date that's got me a few working boards.

Ive been working on a board for awhile- nearly there but am a little stumped. I've checked for broken traces and continuity across the board, done all the basic stuff - 5volts at VCC verified roms, there are no pins which are dead and or floating. I cleaned out sockets with de-oxidit ran the toothbrush all over this badboy and it looks like it just came off the shelf from 1988.

All inputs/outputs, clocks and control pins are doing their thing as per expected I've got a graphical glitch on the board associated with moving objects- (not fixed in one particular spot). Ive checked all 161 counters which are the last point of output before the signals rolls to the CPU (the CPU checks out got a spare as a test unit) and they all have activity.

I started piggybacking ttl's over one another and may of found a glitchy chip, however I don't really want to be piggy backing as a means to identify faulty chips. I want to learn what causes the glitches. My question is what is the best method to fault find ttl logic in circuit.

I have a little 20mhz hantek usb scope and have tried triggering some I/O's but am really green with regards to understanding what it is I'm looking for on a faulty chip, and cant seem to get a stable single shot image as reference both in auto and or normal modes. Reading various things online some argue a digital scope is necessary others an analogue which tbh I'm leaning towards looks a little simpler to operate and others argue a probe, pulser and a comparator are all you need to get the job done. I'm across truth tables and boolean so thinking I can isolate the video board and power up independently, If im to pulse a few inputs could I then just measure the output voltage and if that doesn't marry up, would that tell me, I have faulty IC?.

What causes a faulty ttl?, None of these guys seem to be running overly hot the fault appears straightaway and as mentioned I've got sub 5 volts to each IC.

The stuff I work on is namely 80-'s 90's arcade boards 7400 series TTL gear all running either z80,68k or 6502 processors so sub 7- 10mhz clk signals. Id like to get my head around using a scope a little more thoroughly but not sure what conditions would the chip in question need to met to determine if its good or bad. Do I just compare an input via an output or do I need to probe the respective clock or o/e pins. What time base do I measure ttl signals in and finally is it ultimately just poor voltage that provide a "dirty" square wave, (if so my pulser theory would do the trick). Most vids I've seen are showing a scope testing ttl's are on a breadboard with just a single value held at the input not a chip oscillating at 6mhz

Ideally if somebody could chime in with with thoughts on techniques and possibly a how to guide on reading and using a scope if needs be that would be ace. Hope I've thrown enough info above that makes sense!

Cheers in advance

Y

[David Hess]

The long term TTL failures that I have seen all appear to be contamination problems either inside or through the plastic packaging along the pins, so there is not much to be done there.

Failures have all been either bad inputs, or stuck outputs.  In the later case with stuck outputs, diagnosis has been relatively easy because the output will never toggle, which is trivial to see on an oscilloscope, but a logic probe with pulse stretcher might be just as good or better.

[Yngbld]

Hi David thanks for the reply

Possibly oxidation along the back of the pins might be the issue here as mentioned I have all relevant activity on the pins no stuck or dead pins. So in this case where we have activity on pins, what are you suggesting that I just start shot gunning the board?

[tggzzz]

Apart from David Hess' points.

General debugging 101...

Check power rail voltage and ripple (voltmeter on AC). Decoupling capacitors "wear out" in various ways, and the resulting ripple on the power lines can cause subtle intermittent faults.
Check/wiggle connectors to remove oxidation. Occasionally solder joints can become cracked.

TTL specifically... Use scope to measure voltages and waveforms:

• for TTL check outputs are above 2.4V or below 0.4V; for inputs check inputs are above 2V or below 0.4V. Exception: busses can float between read/writes, but must be correct at the relevant times
• be aware non-TTL (if any) has different thresholds
• ensure clock/OE/CE transitions are clean with no glitches
• for inputs on clocked ICs, ensure inputs are stable before (tsetup) during and after (t_hold) the clock.

How to use scope:

• 20MHz is lower than desirable for signal integrity, but better than nothing
• use a short probe shield lead connected near to the signal you are checking
• triggering starting point: DC, ~1.6V, +ve or -ve ege
• trigger source: for clocks, that clock signal itself. For input/output data signals, trigger on the relevant clock
• sweep speed: often as fast as possible, but slower where you need to see an entire clock cycle
• persistance: once triggering correctly, as long as possible

Multiple sweeps will be overlayed on the display, and you will see an "eye diagram". See https://en.wikipedia.org/wiki/Eye_pattern for examples (ignore non-two level signals such as PAM!)

You are looking for signals that don't obey the TTL voltage and timing rules.

[Terry Bites]

Here's interesting. https://www.ti.com/quality/docs/estimator.tsp#resultstable
Put in a TI part number and get the mtbf.
I'm sure other vendors have similar data available.
Check for MTTF or MTBF or FIT data.
I recall that flipflops have shorter live's. Or did I dream that?

Plastic packages are not hermeticaly sealed and gases and moisture can find their way in.
ICs that have sat idle in the drawer are vulnerable.
SMD components and pcbs get a "bakeout" before assembly, If you don't do it components can fail, sometimes even burst.

[CaptDon]

TTL is a nice logic group to work with and lots of boolean choices!! Your worst fear with TTL occurs at logic 'low'. This is where TTL suffers when even the smallest of noise glitches will cause unwanted clocks and trigger events. One of the families 74ACT I refuse to use because even a 1ns glitch will trigger them. You can't even breadboard with clocked 74ACT because they simply go crazy!! Pay attention to ground loop noise and grounding issues and I2R losses in the ground rails. It is not uncommon to see .1 to .2 DC volts of differential across the negative return rail of a poorly designed circuit board and for sure it will tend to be glitchy especially in a multi board layout!! Surprised you could troubleshoot anything with the piggyback method!! Seems like a good way to destroy I.C.'s and if the bad chip has a stuck output then a piggyback proves nothing!! Piss poor way to troubleshoot indeed!

[David Hess]

So in this case where we have activity on pins, what are you suggesting that I just start shot gunning the board?

I have done a couple of arcade board and test instrument repairs involving TTL and other digital logic families and proceeded by working back through the schematic based on the symptoms to try and narrow down the search area on the board.  Shotgunning the whole board was a last resort.

[CaptDon]

Any old board with Texas Instruments I.C.'s with black tarnish on the silver plated pins...Start with a bath in warm soapy water and a soft tooth brush and clean the silver oxide and tin whiskers from between the pins of the I.C.'s. I have fixed many boards that way!!! Rinse well with warm water!! I generally use a hair dryer on medium to flush the water from under the I.C.'s and when you think its dry keep on drying!!

[Terry Bites]

A DIY octopus curve tracer set to 4V is handy tool for diagnosing dead outputs. Yeah, ground noise and bounce are buggers.