Help with HP 8116A

[MarkL]

I just verified the sequencing on U17 (LS138).  The firmware is enabling it, and keeping it enabled WHILE changing the select inputs.  That is just bad design, since it creates a dependency on the internal delays inside the LS138 to not glitch any of the outputs.

It's ok in situations when glitches don't matter, such as a logic circuit that's purely combinational, but we're driving an edge sensitive /WRITE pin here.

My mistake for assuming proper usage.  That's unusual for HP.

Screen shot below.  They get away with it, and it's why they don't use output 0.

When SELA, SELB, SELC are all 1, that causes the /WRITE output to go low.  The other 6 possible combinations are used off-board.

I would still look closely at U17 and U21B to verify proper operation.


EDIT: Also, I missed a couple of sections of U21A (pins 8+12, 6+14) feeding U17.  Should probably take a look at those too.

Hope all the previous info helps.  If I'm just stating the obvious for you, please say so.

[pelule]

Hi MarkL

Hope all the previous info helps.  If I'm just stating the obvious for you, please say so.

In deed all your info helps, if there is some obvious information, this helps also. It confirmes my own understanding of the system.

100nF?  That's a lot.  You're going to kill the /WRITE signal.

I am not fully convinced yet, the 20ns /WRITE pulse is the root cause.
If I look in the ICM data sheet (page 6) this extra pulse would shift the 8-digit data by one digit, so there should be something visible on the display all the time.
But this 20ns short /WRITE pluse violates the min WRITE time (~250ns, page 3). This may cause an unpredictable conditions in the ICM, which is an realistic possibility out of my expericance with digital circuits.
So I will do this quick check with the capacitive load first (not as a final solution).
Your right for the 100nF. I will starting at ~10pF and increase the value until the pulse is gone. This check can be done very quick and give confirmation or prevent us to run into the wrong direction.

Keep you updated.

BR
PeLuLe

[MarkL]

I had already looked for glitches on all the outputs of U17.  There were none on my unit (despite how HP was controlling the SEL lines).

I think the 20ns pulse is a symptom.  Given the 1us cycle time of the processor and the circuit design, there's nothing that should be creating a pulse this short.  Hiding the issue with a capacitor may or may not make the display behave, but you still have the random LEDs on the LS374s to contend with.

I would try to find why the 20ns pulse is happening.  I think it will lead you to the root cause.  Track it backwards starting with the 3 SEL lines on U17.  See if all the lines are changing at exactly the same time.  If one is skewed by 20ns, you'll see glitches on U17's output.  If the SEL lines looks ok there, continue backwards and look at the SEL lines on the output U18 (which feed U21).

If ok there, it could be U18 is getting a glitchy clock on pin 11 and latching more than once per processor cycle.  Note that U14 pin 12 drives the clock on U18.  U14 (LS138) is common to both the LS374 LEDs and the ICM7218A.  Although it passed the signature test, it could be the problem.

The 20ns pulse could also be a problem with the ENABLE line on U17 pin 5.  Check to see if it's synchronized to the 20ns pulse.  It's being driven by U21 pin 7, which is driven by U18 pin 16.  U18 pin 16 also drives the clock on the device bus latch U16.  U18 is therefore another chip in common with the random LED LS374s.  And it's in common to the data input to the ICM7218A.  Hmmm....

If you have pulse width trigger on your scope, you could set it up to trigger on, say, 10ns to 30ns so you can trigger on the 20ns pulse on WRITE.  Then while triggering on that, use a different channel to poke around at some of the above signals to see if you can find transitions that are synchronized to the trigger.  Wherever you find transitions, that's a signal that could be involved in the 20ns pulse and needs to be investigated further.

Keep in mind that with LS TTL you're going to encounter gate delays in the same range as the 20ns pulse, so to make sure you capture the transitions you'll want set your sweep so you can view 100ns to 200ns of the pre-trigger waveform.  Because the processor cycle time is 1us, nothing should be changing more often than that on the these data buses.

[pelule]

I think the 20ns pulse is a symptom.  Given the 1us cycle time of the processor and the circuit design, there's nothing that should be creating a pulse this short.  Hiding the issue with a capacitor may or may not make the display behave, but you still have the random LEDs on the LS374s to contend with.

I fully agree, the CPU clock does not allow such a short pulse/glitch, so it is a symptom of a mailfunction.

I would try to find why the 20ns pulse is happening.  I think it will lead you to the root cause.  Track it backwards starting with the 3 SEL lines on U17.  See if all the lines are changing at exactly the same time.  If one is skewed by 20ns, you'll see glitches on U17's output.  If the SEL lines looks ok there, continue backwards and look at the SEL lines on the output U18 (which feed U21).

My scope does not have a pulse witdh trigger, thus trigger is not easy, but could manage.
First I checked U17, all inputs are fine, but the output signal was not as stable as I would exspect at unchanged input. So I replaced it.
The glitch is still existing, but the display is now "more stable".
At "all on" the most LEDs are ok now, but not all of the 7-segments. There are still random changes (depend on the pressed button) and still dim, if no button is pressed.
It looks a bit like a weak ground, but that I checked that.
I check also the +5V, if there are any glitches, but none.
It quite late, so need to continue next day to measure backwards and the clock lines. I Will also add some updated pictures.

[MarkL]

Could you post some screen shots of the signals you're seeing?

It doesn't make sense that you're still seeing the 20ns pulse coming out of U17, and all the inputs are ok.  Plus now you've replaced U17, so chances are extremely small you have a second bad U17.

One of the SEL inputs to U17 must be skewed by 20ns.  A skewed signal could also be caused by one of the input edges being very slow.  Did you look at all four inputs at the same time (3 SEL plus the ENABLE)?  And check the rise/fall times?  Should be on the order of 2-3ns, and perhaps a little more for ENABLE since it goes more places.

Sounds like you checked the signal voltage levels and they're ok.

Good idea to check the +5V and ground connections.

What model scope do you have?  I will keep suggestions within the capabilities.

[pelule]

What model scope do you have?  I will keep suggestions within the capabilities.

My scope is a Voltcraft DSO 3062C, hacked for 200 MHz, two channels

Could you post some screen shots of the signals you're seeing?

I also attached
- some new pictures af the 8116A display.
    You may judge the difference in brightness in bad_0 and bad_1.
    In bad_3 the disgits are as brigth as I expect a working tool.
- some screen dumps of the oscilloskop.
Osc-Trigger condition:
    external, falling edge, level 1.00V
    U18, pin 19 = MODE
Osc-blue shows (2.00V/div):
    U18, pin 19 = MODE (just for reference)
Osc-Yellow shows (2.00V/div):
    OSC_0: U17, pin 7, WRITE
    OSC_1: U17, pin 7, WRITE
    OSC_2: U17, pin 16, VDD
    OSC_3: U17, pin 8, GND
    OSC_4: U17, pin 8, GND
    OSC_5: U17, pin 7, WRITE

It definitively a glitch, the level is strong enough, the locig analyser detects a 20ns low pulse.
Cause must be a switching part which need such high current, that it disturbes the levels on any signal.
The critical circuit is located somewhere on the CPU/A3 board.
There is no change if I disconnect GPIB and the flat cable to A2/Control board and to A1/Main baord.
Only A4/Display board and the supply are connected.

So my next plan is:
use the same setting as in picture "OSC_1_2us_MODE_WRITE"
Set the 8116A into "auto" increment mode to get the scope continously triggered
Seach/Measure, which signal is synchronous to the glitch.
Replace the related IC.

Any other sugestion, which would lead to a more efficiant search, would be highly welcome.

BR
PeLuLe

[pelule]

next pictures...

[MarkL]

I'm still looking at this new information, but my first question is how are your probes grounded?  Are you using the shortest possible ground wire and attached to a ground at the chip you're probing?

The sweep speed of 400ns is a little slow to see the detail, but it looks like ringing from too long a ground path.

If you have a ground spring clip, you might want to try probing with it on some of these signals to verify what you're seeing is real.  If you can, put the spring right on the ground of the chip your probing.

[pelule]

Ground was connected to U17 pin 8.
the ground connection may have a certain influence, but this does not fully explain the "20 ns pulse" detection of the logic analyzer at the first glitch after falling edge of MODE you see at picture OSC_1.
But for confirmation I will use a Pintek differential probe to measure at a single channel only (WRITE and MODE signal).
BR
PeLuLe

[MarkL]

I see what you mean.  Besides the glitch, it's interesting that WRITE gets pulled down a little.

The drop on WRITE is synchronized with the loading of U16, the LATCH BUS latch.  It happens a tiny bit on my unit too.  Below is an example showing it synchronized with LD1, but many of the other LD lines go low at the same time depending on what's being displayed.

The drop is not happening through the +5V supply to U17, since you've checked that.  And it's probably not happening through other pins on U17, but you can verify that.

So, it seems likely it's only happening on the WRITE line, and that only goes to U22.

Perhaps take a look at U22's Vdd, pin 19?  R2 and C8 supply and filter Vdd to U22.  Maybe C8 has a problem?

I'm not sure why there's a stub on top of U22 pin 19 that goes to +5V.  I think it's a mistake on the schematic.  It doesn't appear to be on my unit, but I can't be completely sure because I can't see under U22.

Maybe take a look at the LD lines to see if U16 is struggling to make one of the lines low?  Seems likely you already did this.

[pelule]

Hi Mark,
thanks again for digging such deep into my crazy problem.

Perhaps take a look at U22's Vdd, pin 19?  R2 and C8 supply and filter Vdd to U22.  Maybe C8 has a problem?

Seems to be the best tip ever. Just wondering, why I haven't seen that myself.
Unfortunately I am out on a business trip, so I need to wait until Friday evening to check.

But thinking on your great hint, it sounds more and more reasonable:
if C8 (or R2) is bad, this would cause a lower VDD at U22, when U22 starts muxing the LEDs and driving current. This would explain several effects like the mostly dim display, the time-to-time random content and also the voltage drop at the WRITE inputs (creating a current via the internal circuit similar to a diode).
As I have soldered a socket for U22 already, it will be quite simple to check (also, if the schematic has an error)

The drop is not happening through the +5V supply to U17, since you've checked that.  And it's probably not happening through other pins on U17, but you can verify that.

Already done, is not happening.

Maybe take a look at the LD lines to see if U16 is struggling to make one of the lines low?  Seems likely you already did this.

Yes, done already. It's not the case.

BR
PeLuLe

[pelule]

Hurray - failure found. Tool runs perfekt again.

Mark, thanks a lot for your great help digging into my problem.
Proofs again my slogan:
  you will learn something new every single day. No matter how old you get, no matter how much experiance you have.

Perhaps take a look at U22's Vdd, pin 19?  R2 and C8 supply and filter Vdd to U22.  Maybe C8 has a problem?

That was the break through tip.
I measured resistor R2 and it was high impedance (open). Touched it a bit and it was broken (see pictures).
So the ICM dragged the supply current via the logik inputs protection circuits. C8 buffered shortly higher current requirements
As soon some LEDs had to be driven, the supply voltage dropped and caused to the random result.

Replaced R2 and now everything is fine.

Yet need to clean and to do the performance testing.

As I have soldered a socket for U22 already, it will be quite simple to check (also, if the schematic has an error)

Measure and looked to the traces. It's an error in the schematic, U22 pin 19 does not go to +5V, just to R2 and C8.

Thanks again a lot for you experianced help. Hope to get the chance to return the favor.

BR
PeLuLe

[MarkL]

Excellent!

Glad to have been of help.  I'm surprised the display was as bright as it was given that it was just running off the logic inputs.  The extra low retention voltage of 2.0V on the ICM7218A probably contributed to keeping it running longer since C8 was holding up the Vdd pin.

If you look closely at one of your earlier pictures of the whole board (bad_000_board.JPG), you can see that something isn't quite right with R2.  But it's hardly something that stands out in the picture.

What helped the most was the scope traces.  A scope trace is worth a thousand words, right?

Good luck with your 8116A.  I have other more modern function and signal generators, but I usually reach for the 8116A first.  It's just so easy to use.

[pelule]

If you look closely at one of your earlier pictures of the whole board (bad_000_board.JPG), you can see that something isn't quite right with R2.  But it's hardly something that stands out in the picture.

Yes, that picture showed it already.  Attached the area a bit zoomed.
I guess I need to go and to let my glasses checked.

A scope trace is worth a thousand words, right?

Absolutely right, there is noting to argue against that fact.

I also have a modern 2-Ch 20 MHz signal/arbitrary/function generators, but as you said, the 8116A is such easy to use, I allways take it. Only in case I need the precision or stability of a crystal based generator, I use the modern one (not that often in fact).
I guess, that's the reason, the 8116A was build for such a long time and is still quite expensive on the bay.

BR
PeLuLe