Author Topic: Help with HP 8116A (Read 38333 times)

George_Race · « **on:** July 21, 2014, 12:25:21 pm »

I am trying to repair an HP 8116 Generator.
When turned on most of the front panel indicators flash and a "1" flashed on and off in the first digit position. It then goes blank, no lights on and the fan runs. The old battery has been removed and I do not see any corrosion in the area. Scope traces show that the processor is running, but there is no scan information going to the front panel via the wide flat cable.

All power supplie voltages check OK. If I turn on holding down E.WID & the sine button it shows RPT and OFS on the front panel, no other indicators are on.

I have looked closely at all the board components and there is nothing that looks out of place. I do have the service manuals and schematics/layouts. I note that my Processor Board is made in Germany and is version 8116-66503. I can only find a partial board layout in the update section that shows the row of eproms at the top of the board. Update 41 I think.

Does anyone have an idea of where I should start the trubleshooting?

George

free_electron · « **Reply #1 on:** July 21, 2014, 02:12:31 pm »

Battery removed or replaced ? Battery needs to be there. There is a monitoring circuit that halts the cpu if the battery is too low (or not there)

George_Race · « **Reply #2 on:** July 21, 2014, 06:14:01 pm »

Thanks I did not realie that! I read that the battery was only needed to keep a backup of the last configuration that you had when you turned it off. Without the battery I read that it would simply load the defauly configuration.

Maybe that is the difference with the German Veresion, 8116-66503.

I will install a 3 volt battery and see if it helps.

Thanks,
George

free_electron · « **Reply #3 on:** July 21, 2014, 06:46:44 pm »

there are at least 4 different cpu boards.
there is one with like 6 or 7 proms , one with 2 proms and 2 rams, one with 1 rom and one ram.
lots of stuff went obsolete during the lifecycle of these machines. ( this generator was made for a very long time)

the really old boards don;t care about the battery. the newer ones do.

MarkL · « **Reply #4 on:** July 21, 2014, 08:55:21 pm »

Try the battery, but from what I see in the service manual it doesn't matter if it's present or not (in any revision). There's no monitoring circuit I can see.

What serial number is your unit?

It sounds like the processor is not getting a chance to run for very long. Are the bootup symptoms exactly the same each time?

What scope traces "show the processor is running"? Are you looking at address and/or data lines? Any stuck? You might try this with the processor in "free running mode", see 10.7-17.

Which service procedure section has you holding down E.WID and SINE? (Just not familiar with that one...)

As you've probably noticed, much of the service manual is oriented towards debugging with a signature analyzer. You might need one for this problem.

George_Race · « **Reply #5 on:** July 21, 2014, 09:06:57 pm »

This processor board is made in Germany. Board is version 8116-66503. Has 6 EProms across the top of the board and is considerable different from the schematic diagrams that I can find.

Hopefully someone can point me to a COMPLETE schematic of that board version. It is listed by HP as their Update 41 with a partial layout and schematic. But would be nice to have the full board layout and schematic.

Thanks for your comments, I had hoped that the battery would fix it, but unfortunately it still is the same.

There is very little signal activity on the board, there does not seem to be any scanning of the address lines going on. Am going to explore the reset components next, just in case something has failed in that circuit and it is holding the whole board in limbo.

George

George_Race · « **Reply #6 on:** July 21, 2014, 09:41:09 pm »

Hi Mark, looks like you and I were posting at the same time!

This instrument was German built. Serial Number is: 2334G02413 so consequently has the 8116-66503 version Processor Board. The free run procedure on 10.7.17 is not going to be the same on this particular board. I think I have it figured out but would like a confirmation before giving it a go.

Here is a picture of what I think is the free run jumper point on this board.

The four test points at the top are marked: RES NMI

The jumper is across the P0 tabs. I think it needs to be moved to the PI tab to go into free run.

So now how do you think I should proceed, following the procedure on 10.7.17?

A step by step detail would be appreciated.

Also any idea where to get the layout and schematic of this board?

Thanks,
George

free_electron · « **Reply #7 on:** July 21, 2014, 10:12:57 pm »

i have a fairly complete service manual for this beast. ( paper copy ). let me check tonight.

i don;t have a 8116 anymore myself. sold mine off two years ago ( i had 4 ). i've probably repaired at least 15 of those.

look around the battery there should be an lm339 a grey resistor pack and two TO18 transistors. those are the monitoring circuit. i believe there is a NOr gate as well. if the battery voltage is lower than the incoming they switch to incoming. if the battery voltage is too low they hold the cpu in reset to prevent ram corruption.

The free-run doesn't help you . free-running is the mode used if you have a signature analyser.
the board with the 7 eproms is fairly old.

double check both the 5 volts and the 5.1 volts coming through the 4 pin cable close to the battery.
double check the fuses on the main board close to the transformer.
check that the fan is running. some machines have a fan-fault circuit.

when you power up : does the machine do its all segments test or not ?

hit the LCL button to see if it will skip out of fault mode.

MarkL · « **Reply #8 on:** July 21, 2014, 10:30:20 pm »

Hi George,

I think your best bet on a schematic would be to look for an old version of the service manual that goes up to change #28 (according to the backdating table for your serial number). Otherwise, I you're likely stuck with HP's backdating scheme.

It seems that the processor is not running, so "free run" would be a good way to observe the address and data and other control signals coming out of the processor. The procedure says to move the jumper to P1 and also disconnect A2W2.

You should see the address incrementing at least. In particular I would look for any data or address lines that *weren't* changing state. Unfortunately without the signature analyzer, this isn't going to prove it's working or that the ROMs are good, but at least you should be able to see anything that's stuck.

By setting up triggering on the various chip selects for the ROMs, you should be able to determine if they're outputting data. You can also try working through the signature table to verify signals are changing there too.

If you have a EPROM reader, it might also be worthwhile to verify their contents if you can find a copy of the firmware lurking on the internet somewhere.

Was this unit working at any point? Or did you get it this way?

George_Race · « **Reply #9 on:** July 21, 2014, 11:44:11 pm »

Free_Electron & Mark:

Sure do appreciate your suggestions with my problem 8116!

I checked the voltage to the 4 pin connector near the battery. One of the pins has +5.16 another has -12.79 volts. All of the power supply voltages are very close to spec. No blown fuses, fans run very nicely when turned on. When turned on several of the leds on the left side flash, the left display digit shows the number 1, and the RPT and OFS panel indicators stay on. Everything else on the panel is dark.

Looking the the ribbon cable from the display unit, there are various pulse width signals on 5 of the many leads. Some of the other remaining leads are either high or low. I moved the jumper to free run and absolutely nothing changed on the address or data lines.

Looking at all the pins on the processor, the majority have square wave date of various widths and frequency. Moving the jumper to free did not seen to affect any of those signals. My next step may to be note what each of the processor pins is doing, compare it to the schematic and see if there is any kind of a pattern addressing the sets of address and data line feed points. Not sure this will really prove anything, but gived me something to do I guess!

I am concernded that there may be some kind of a reset malfunction that is holding off scanning/addressing of the front panel as well as other areas. I am going to try and figure out the reset system as well. Would be nice if I know if it was normal high or low! Maybe I can find that in the service data as well. Guess I need to read through the service info carefully.

This unit is absolutel pristene inside and out. I bought it for a very reasonable price on ebay, hoping I could find and repair the problem it is having.

Any further information or things to try will be helpful.

Thanks a bunch,
George

MarkL · « **Reply #10 on:** July 22, 2014, 12:40:08 am »

Quote from: George_Race on July 21, 2014, 11:44:11 pm

I am concernded that there may be some kind of a reset malfunction that is holding off scanning/addressing of the front panel as well as other areas. I am going to try and figure out the reset system as well. Would be nice if I know if it was normal high or low! Maybe I can find that in the service data as well. Guess I need to read through the service info carefully.

There's a /RESET and a RESET. The processor uses /RESET (active low) and it's on pin 40, so you can check that, and RESET is on U35 pin 2. The reset circuit has a lot to it; it's on schematic page 10.7-9, and there's a brief description on 10.7-6. But if you're seeing active digital signal levels around the processor, it's probably running something (maybe garbage) and not being held in reset.

MarkL · « **Reply #11 on:** July 22, 2014, 01:16:29 am »

Quote from: George_Race on July 21, 2014, 11:44:11 pm

When turned on several of the leds on the left side flash, the left display digit shows the number 1, and the RPT and OFS panel indicators stay on. Everything else on the panel is dark.

Looked into this to see if there's any correlation and there doesn't seem to be. RPT is LD2'', OFS is LD2', and the high order "1" digit segments always come on as a pair and are called LD5'' (odd naming convention using prime and prime-prime).

LD2' and LD2'' are derived from LD2 (latch data bus 2), and LD5'' from LD5. Single prime LDs are output from U23 and double prime from U24. Both are 374 latches and have lots of other segments on them.

Most likely this is the way the latches initialized from power on and were never set or reset via the processor. I wouldn't give much weight to this combination of LEDs being on as being related to the problem.

As free electron stated, the first thing the processor does is turn on all LEDs for a second or two and it's not even getting to that.

Actually, I noticed before it turns all LEDs on, it checks for stuck keys. If it finds any it displays an "o". You could hold down a key to see if it does that, but I'll bet just about anything it's not getting to that either.

My initial suspects are the processor or the ROMs, or another chip sitting directly on the data or address bus, or associated control lines, that's interfering with the processor executing code properly out of the ROMs.

George_Race · « **Reply #12 on:** July 22, 2014, 02:29:25 am »

Sure do appreciate the conversation we are having so far.

Did a lot of logic looking the past couple of hours. I have found that the Display Driver, U22, is showing some unusual conditions. Several of the leads are showing a perminant high condition with just a slight bit of address pulse showing at the top. Looks like the high condition is 4.5 volts, the pulse on top of that is about .5 volts. Many of the pins are showing good full 5 volt pulses.

Unpluging it from the front panel display board does not change any of the above levels, so the problems is on the Processor Board. I made a chart that indicates which pins are OK and which have the high condition and small pulse. Tomorrow I will chart what address/data lines are affected. That should help me to find out what the affected signal pins have in common.

Gosh, I suspose that the Display Driver chip could be bad! Any thoughts from you guys would be appreciated.

Time to call it a night,

Thanks again for all the suggestions and comments,
George

MarkL · « **Reply #13 on:** July 22, 2014, 02:22:57 pm »

Well, that's interesting on U22. Which pins are permanently high?

U22 is isolated from the CPU buses by a bunch of latches (the "latch bus"). So, even if U22 has stuck high pins on it, it doesn't seem likely it would prevent the CPU from running. Plus there are parts of the display that are not handled by U22, and those aren't working either. However, U22 or some other chip could be taking down the entire latch bus (appears on U22 pins 7 5 6 10 14 13 11 12).

And when you said there was no keyboard scanner activity in an earlier post, you were looking at U19 and U20? The keyboard scanner is not dependent on the latch bus. That might be a clue.

free_electron · « **Reply #14 on:** July 22, 2014, 05:01:05 pm »

i may still have a few cpu boards laying around. i'll dig in the 'pile' tonight . i need to fish out some stuff to send off to other people as well. ( i dread going in that section of the lab. it becomes a huge time sink as i always find something long forgotten where i go : hey i should give this thing another go at trying to make it work.. )

George_Race · « **Reply #15 on:** July 22, 2014, 08:15:52 pm »

Mark, I will get back to you later with information on the pins that are stuck high.

Free_Electron, boy that would sure be teriffic if you have a replacement just laying around.

Have been working in the macnine shop most of the day, going to have a bite to eat and then do some more data logic looking on the CPU board.

George

George_Race · « **Reply #16 on:** July 22, 2014, 10:37:19 pm »

Mark, a few things about U22, the display driver.

The following pins are at +4.5 V with a .5 v pulse on top.
5-6-7-10-11-12-13-14-21-24-25-26-27

Interesting to note: Pin 13 changes and has a nice normal 5 volt pulse when RPT & OFS are both on.

The following pins have a full size 5 volt pulse.
8-9-15-16-18- and 13 when RPT & OFS are both on.

The following pins are setting at +5 Volts, no pulses showing.
1-2-3-4-17-19-24-25-26-27

The following pins are setting at 0 Volts, no pulses showing.
20-22-23-28

Hopefully some of this makes sense,
George

MarkL · « **Reply #17 on:** July 23, 2014, 03:52:27 pm »

That's some very interesting info on U22.

So, to break it down: All pins on the latch bus are high, *except* LD2 (pin 13). LD2, through another pair of latches (U23 and U24), also controls RPT and OFS. (Although you also put pin 13 in the "always high" list - perhaps a typo?)

It could be that the latch bus driver (U16) is not working, or it's working and it's fighting with a dead or errant chip that's holding most of the latch bus lines high.

At this point I would verify power supply levels on all chips connected directly to the latch bus (U16, U22, U23, U24, U25, U26, U37). Also check U18 since it's controlling U16, and U21 since it's controlling U25. And when I say verify I mean measure directly across the pins on the chip to make sure there's not a cracked trace or bad solder connection somewhere.

Next, there are only two chips I see that can output onto the latch bus: U16 and U25. They could be fighting each other if they're on at the same time. Check the control signals going into both of them (U16 pins 1 & 11, U25 pin 1).

We're not quite there yet, but if it turns out that 1 of the 7 latch bus connected chips is likely bad, it might be tricky to track down which one it is. What test equipment do have to work with? Are any of the suspect chips socketed on your board?

George_Race · « **Reply #18 on:** July 24, 2014, 12:15:46 am »

Hi Mark:
I just printed out your last comments. I will try to work through the list and see what I can discover.

At the moment I am concentrating on the CPU signals. I will have a list of what is going on with the CPU later this evening.

As far as test equipment goes, analog scope, digital scope, Spectrum Analyzer, signal generator, RF milivoltmeter, standard AC/DC/ohm meters. Most everything is HP expect for the digital scope with is TEK.

Have been building, designing, & servicing digital and analog circuits since the early 60's. TTL, HTL, RTL, CMOS, etc...all since their inception.

Getting up in years, but still enjoy the challenge of bringing a piece of great older equipment back to life.

George

George_Race · « **Reply #19 on:** July 24, 2014, 01:42:44 am »

Hi Mark:
Pin 13 is the one that changes its state depending on whether or not the two LED, RPT & OFS are on or off.

Tonight I finished looking at the CPU operation. I do think that it is working properly. I see the 4 MHz on pins 38 & 39. I see 1 MHz on 37 and pins 9 thru 25 have very nice clean square wave signals in order from 500KHz on pin 9 down to 15.3 Hz on pin 25. (21 is GND) So it appears that the CPU is putting out all 16 address lines correctly. Pins 4, 5, 6 & 40 are high. Pin 7 is low. Also 34,35,& 36 are all high. Pin 31, which is the D2 line, is putting out a negative going burst of 4 pulses with a rep rate of approximately 1 Khz. That translates into LD2 that is probably turning on RPT and OFS. (Just guessing!)

All of the other Data Lines from the CPU are just noise with pulse width and height varying greatly. There is nothing that I can sync on with either the analog or digital scope. Is one big mess of digital noise!

I checked between VCC and Gnd on all the chips this evening, using a VOM. All are setting at +5.1 VDC and it is very clean and solid.

On the board the only socketed device is the CPU. Incidentially, I ordered a new CPU and the LED Driver, U22 along with a socket. I will change those out when they get here next week. But, based on what you are telling me, they may not have anything to do with the actual problem. And, I do not have any idea how to isolate and troubleshoot the various chips residing on the latch buss.

So, Mike I guess I await your next thoughts and ideas.

Thanks for all the time you are putting in trying to help!
Greatly apreciated!
George

Forgot to mention in the post above that when I went to turn off the Generator a bit ago, the ADS LED was on as were the AMP and HIL backlit indicators.

Just some more to think about!
GR

MarkL · « **Reply #20 on:** July 24, 2014, 02:45:37 am »

Ok, thanks for the probe on the CPU. We'll put the latch bus aside for the moment.

There's nothing I've seen yet that concludes it's the CPU or U22, but there's also nothing yet that rules them out as the culprit. You might get lucky.

You've presumably taken the unit out of "free run" since CPU pin 36 is high. Right?

If so, I think it's quite strange the addresses are incrementing so nicely and in order, from what you describe. I think you're saying each higher address bit is running at exactly half the frequency of the previous. Ordinarily the address lines would be fairly random in appearance, especially the lower order ones, if the CPU was executing real code. Not unlike what you're seeing on the data lines.

You should check to see if the CPU is reading from one or more of the ROMs. The chip select for the six ROMs are conveniently brought out for you on TP1 - TP6. You should see enable pulses on one or more of those TPs. That's the next thing to check.

George_Race · « **Reply #21 on:** July 24, 2014, 11:48:40 am »

The 6 EPROM test points, 1 thru 6, are all showing a negative going 2 pulse train at a rate of 36 Hz.

Yes, the free run jumper is in position P0. Interesting to note, when I put the processor in Free Run, position P1, it stops all the data bus "digital noise" activity. But still nothing on the front panel display.

Yes the CPU address lines are divide by 2 all the way down to 15.3 Hz. All very nice clean square waves.

George

MarkL · « **Reply #22 on:** July 24, 2014, 04:11:10 pm »

"Free run" looks like it puts the board in a mode where it forces 0x5F (CLR B) instructions onto the CPU data lines for every read cycle. The CPU is then expected to increment through all the memory addresses as a test.

But even in regular mode the CPU is doing that! It's as if it's ignoring instructions being presented to it on the data lines even though from your testing the data lines are changing. Because the ROM chip selects appear to be working from your latest test, the data that's showing up is probably what's being read out of the ROMs as the CPU blindly cycles through all the addresses. I say probably because we're not looking at the exact timing of these signals and also verifying the data on the ROM pins is the same as what's showing up on the CPU data bus.

I also think it's strange that VMA (Valid Memory Address) pin 5 is high *all* the time. This is not impossible, but I think highly unlikely since it says every cycle, as qualified by E pin 37, is a read (because R/nW is also high). Can you double check pin 5?

Are you also seeing a perfect 1MHz on U15 pin 6? (this is E * VMA)

The next thing to look at is to see if the CPU is reading valid data. A logic analyzer is a better tool for this, but you can do a rudimentary check with a scope. Set up to trigger on the falling edge of E (pin 37), and verify again that VMA and R/nW are always high on the falling edge. This is when the CPU is actually latching data from the data bus.

Now look at the data lines and the values at the falling edge of E. Any pattern there? Anything always 0 or 1?

free_electron · « **Reply #23 on:** July 24, 2014, 05:43:19 pm »

check the free run logic. there may be a 74245 or 373 that is dead.

MarkL · « **Reply #24 on:** July 24, 2014, 08:46:54 pm »

Quote from: free_electron on July 24, 2014, 05:43:19 pm

check the free run logic. there may be a 74245 or 373 that is dead.

The free run logic consists of dragging D7 and D5 low with a couple of diodes and simultaneously disabling the 245 bus driver into the CPU data lines (so data = fixed 0x5f). OP reports no data line activity in free run mode, so this is probably working ok.

I agree it could be dead bit(s) on the 245 driving back into the CPU. But since it only drives when E is high, the observation needs to be synced to E, hence the latest test.

It may well be the CPU at this point.

MarkL · « **Reply #25 on:** July 24, 2014, 09:15:26 pm »

George,

If the latest round shows nothing of interest, I have another test for you. This one is a little off the menu.

I'd sure like to see VMA and R/nW do something to convince me the CPU is looking at incoming instructions.

Instead of having free run mode execute 0x5f instructions (CLR B), we could force it to execute 0xdf (STX). STX is a Store Index Register direct. This should cause VMA to have pulses as well as R/nW.

To do this, you would need to unsolder one end of CR1 which will allow bit 7 to be a one and turn the 0x5f into a 0xdf. Put the unit in free run mode and look at VMA and R/nW for pulses. You should also verify that the data lines are indeed set to 0xdf.

The random writes may cause some bizarre behavior in the rest of the unit.

Or... wait until you get your new CPU and try that instead. Just thought I'd throw this out there if you're interested.

George_Race · « **Reply #26 on:** July 25, 2014, 01:23:01 am »

Good evening again guys:

To answer some of the questions ask, first, yes pin 5 VMA is setting high as is 34 R/W

Here is what Pin 37 E looks like:

Here is U15 Pin 6:

And on the last test, I lifted one end of CR1, move the jumper to free run.

R/W remains high, no pulses.

Here is now what VMA looks like:

Not sure when the new CPU will be here, either Saturday or Monday for sure.

And I though that finding the problem was going to be really easy!
Shows just how wrong you can be I guess.

Have a nice evening,

George

George_Race · « **Reply #27 on:** July 25, 2014, 01:12:01 pm »

I have a question. I have been going to buy a signature analzer for some time, but just have not gotten around to it. I think that this would better help me to troubleshoot HP equipment, which I tend to buy and repair!

I like both the HP 5004A and 5005B. I am leaning toward the 5004A because it takes less bench space. I can't seem to find a great deal of difference in the two instruments, other than size.

Would either be suitable for my purpose?

Thanks,
George

MarkL · « **Reply #28 on:** July 25, 2014, 01:41:57 pm »

Between the two I would say the 5005B is a nicer instrument because it has the built-in DMM functions. Either will do the job.

I bought a 5006A on ebay just the other day for the same reason (not even here yet). I've always been able to fix older equipment issues without one, but because the service manuals are written around signature analysis it could be a great time saver.

Perhaps others have direct experience with those two models...

MarkL · « **Reply #29 on:** July 25, 2014, 02:18:00 pm »

But back to the scope traces (and thanks for the photos, they're very informative)...

STX direct is a 5 cycle instruction with 1 cycle of VMA low. The duty cycle on your trace is exactly that. Looks great.

STX direct should also have 2 cycles in a row of R/nW being low. You're not seeing that. We need to find out why.

First, please confirm that 0xdf, the STX instruction, is on the data bus (in the modified free run mode). All data lines should be high except D5. If not, transceiver U2 might be bad. To confirm, U2 pin 19 should be high and this should be disabling all outputs.

If you are getting 0xdf on the data lines, either the CPU is bad or something is forcing R/nW (pin 34) high. What I would do is try to isolate pin 34 by unplugging the CPU, bending this pin slightly, and plugging it back in leaving pin 34 hanging out. Some of the older ceramic packages won't tolerate this, so use your judgment and don't do it if you think it's going to break the pin.

If you can isolate the pin, hook the scope up to the pin directly and see if you get a duty cycle of about 40% on it (again in free run). If you do, next steps would be to find who's holding it high. If not, a dead CPU comes to the top of list.

Also, on your scope traces, that's a really ugly U15 pin 6 (signal: nEVMA). It looks like it's either driving too much capacitance, or the high side output driver is blown. We should come back to that, but let's finish with the CPU first.

George_Race · « **Reply #30 on:** July 25, 2014, 02:26:54 pm »

Thanks Mark, sounds good.

I am also looking at the Sony/Tektronix 308 which is similar and from what I read does the HP signatures as well.

Any thought on that one?

Thanks
George

MarkL · « **Reply #31 on:** July 25, 2014, 04:03:36 pm »

Quote from: MarkL on July 25, 2014, 02:18:00 pm

Also, on your scope traces, that's a really ugly U15 pin 6 (signal: nEVMA). It looks like it's either driving too much capacitance, or the high side output driver is blown. We should come back to that, but let's finish with the CPU first.

Ah, I didn't notice U15 is a 74LS12 which open collector, so it's probably ok. But that sure is a long rise time for a 1MHz digital signal...

George_Race · « **Reply #32 on:** July 25, 2014, 05:19:03 pm »

CPU arrived today. Out working in the machine shop so will not get back to the basement work bench until later today.

Will make the swap and see if anything has changed that we have been following.

George

George_Race · « **Reply #33 on:** July 26, 2014, 01:51:02 am »

Hi Mark, I am starting to have problems telling the trees from the woods! I have looked at so much and tried so many things I am kind of lost as to where I am in the troubleshooting.

CPU arrived today! Installed it and immediately saw a big difference. Several of the front panel lamps came on, including ERROR to the left of the numeric display. But nothing on the numeric display at all. They were on for about a minute and then everything went back to like is has been with the two indicators RPT and OFS on.

Here is the big change! The next two shots are of CPU pins 33 & 32.
All the CPU data pins have varying width signals, except for 31 which is still sitting at 5 volts, no data.
Hopefully this will give a new clue as to another path to follow.

I bought an HP 5004A on ebay today, should be here by the middle of next week. Just maybe doing signatura analysis, I will be able to come up with some more clues along the way.

When I pulled one end of CR1, and went to free run, All of the data pins on the CPU had that ugly waveform, like U15 Pin 6 in the last batch of pictures I sent. (CPU Pin 31 stayed high! No waveform)

I am at a point where I just seem to be going nowhere.

So what do you think is the next step.

George

MarkL · « **Reply #34 on:** July 26, 2014, 02:42:30 am »

Hi George,

Sorry to hear the new CPU didn't work, but it was a worth a try since you already ordered it.

Since the new CPU didn't solve the problem, I would put the old one back in. There's obviously still something wrong unless the second CPU was also bad, which I'm going to assume for the moment isn't the case. The reason to put the old one back in is that we don't want to start introducing new variables, especially with something as central to the troubleshooting as the CPU.

But for all we know, if something killed the first CPU, the second one might have now suffered the same fate.

I'd like to go back to the modified free run test from a couple of posts ago and see if we can find out why R/nW is not pulsing low. That needs to be answered. Can you isolate pin 34?

And you did say it's still high with the new CPU. It would seem more likely now that something is holding it high, maybe even shorted to the +5V rail since the CPU is the only one who should be driving it. It only goes to a few other chips.

One check for this would be to power the unit up without the CPU and see if you can use a 100ohm (or so) resistor to manually pull the R/nW low by grounding one side of the resistor and touching it to socket pin 34. Watch the voltage on the pin to see if anything's fighting you. It should be nearly pretty close to 0V.

MarkL · « **Reply #35 on:** July 26, 2014, 03:19:23 am »

Actually, re-reading your previous post you *didn't* say 34 was high. Sorry about that.

Can you check R/nW pin 34 with the new CPU in modified free run? If still high, the "manually pulling it low" test would be useful.

If it's pulsing now leave the new CPU in there.

George_Race · « **Reply #36 on:** July 26, 2014, 10:51:20 am »

OK Mark, getting back to basics and doing what you ask.

Removed one end of CR1. Put Free Run Jumper to Grounded position.

Here are pictures of what is on Pin 34 and Pin 5.

And, D7, Pin 26 is now low.

These are back on the old processor as well.

As a side note, when I turned on the unit, with the processor removed, Almost everyting on the front panel lit up. Does that rule out U22 as being bad?

Ready for the next test,

George

MarkL · « **Reply #37 on:** July 26, 2014, 04:13:27 pm »

So, to re-cap here...

Everything is as it was before: It's the old processor, in free run with CR1 lifted, and NOW there's a pulse on R/nW? That's inconsistent with the previous behavior. And I would note it's also the wrong length pulse for the STX Direct instruction. It should be a 40% duty cycle.

And D7 shouldn't be a constant low with CR1 lifted. R1 should be pulling it high, for at least part of the cycle while the CPU is doing an instruction read.

I don't want to be hard on the CPU or the socket, but can you check the values of D0 though D7 without the CPU? They should be all high except D5 when in modified free run mode. Maybe even try checking this several times with power cycles in between.

And with the CPU in, it would also be interesting to know what pin 1 (R/nW) and pin 19 (nEN) are doing on transceiver U2. I'm really starting to suspect U2. Pin 1 should be R/nW, and pin 19 should look like ~E, probably with a slow rise time like we saw on U15 pin 6. We may need to do some pin-by-pin verification to make U2 is off the bus when it's supposed to be, and passing data in one direction or the other when it's supposed to be. (This will take some scope state triggering and not just looking at pulse shapes.)

And on U22, it's a good sign all the LEDs and segments turn on. At least it says the output drivers are working.

George_Race · « **Reply #38 on:** July 26, 2014, 10:24:38 pm »

Hi Mark, your recap looks good.

Here is how D7-Pin 26 looks with CR1 pulled and in Free Run Mode.
I put the scope in Auto and this is what it is finding.

Is a pretty small signal!

Next is a picture of U2 Pin 1:

Next is a picture of U2 Pin 19, it is setting high.

Next I pulled the CPU for the following readings:

U1 Pin 26-D7 is Low, all other pins are high.
In order to get D5 Low it would be necessary to open CR2. And that makes D5 go Low, all other pins High.

With both diodes open, all data lines are setting High.

And last is a picture of the front panel with the CPU removed.

The CPU pins are starting to get fatigued and the CR1 and CR2 pads are starting to look bad.

I would like to put the diodes back in correctly and clean up the board, if you think we are done with that phase of the testing.

Thanks,
George

MarkL · « **Reply #39 on:** July 27, 2014, 12:45:57 am »

Hi George,

A couple of things are not making sense. If CR1 is in, and you're in free run mode, it should pull D7 down. And if CR2 is in, and you're in free run mode, it should pull D5 down.

So, feel free to solder the CR1 and CR2 back in. That test is not helping us except it did prove R/nW can move.

Before you put the CPU back in, and with CR1 and CR2 soldered back in, check to make sure all data lines except D5 and D7 are high. D5 and D7 should be near 0.2V since they are being held low by Schottky diodes CR1 and CR2. EDIT: This is in free run mode.

If you're up to it, we can check the function of U2 but you will need a scope that can do pattern or state trigger on at least 2 inputs, with a 3rd channel available for probing. What do you have?

MarkL · « **Reply #40 on:** July 27, 2014, 01:43:05 pm »

Hi George,

This odd behavior with CR1 and CR2 affecting the opposite lines was bothering me and I popped the top off my 8116A to look at it.

Using a continuity tester, I found that CR1 is wired to U1 pin 28 (D5) and CR2 is wired to U1 pin 26 (D7). The component labeling on the schematic (or the board placement, if you prefer) is flipped. Thanks, HP. But this is why I asked you to verify that 0xd7 was on the CPU data bus pins. It's important to double check that changes have the intended effect.

At any rate, since these bits were flipped, the CPU was executing 0x7f instead of 0xdf. The 0x7f instruction is a CLR Extended. That is a 6-cycle instruction which results in 1 VMA low pulse and 1 R/nW low pulse per cycle. That matches the traces you have in post #36. And the frequency is 1MHz/6 = 167kHz which is right. In post #26 the frequency was also 167kHz, which it shouldn't have been, but I missed that and I was just eyeballing the duty cycle.

I still suspect U2, and this is what I wanted to check in post #22. A fairly complete check can be done using pattern/state triggering, but because the enable input is periodic (and predictable), I think it could also be done using a very basic scope with as little as an external trigger input and 2 analog channels. I will try it first on my 8116A and post back. No soldering needed.

George_Race · « **Reply #41 on:** July 27, 2014, 02:01:49 pm »

Good Morning again:

Yes, when CR1 and CR2 are in, D7 & D5 are pulled down by the diodes. And the level is in the area of mV's. That shown in the last set of pictures that I sent.

I am looking at the function of U2.

In free run mode it is in Isolation Mode. Enable, Pin 19 is setting High

In normal mode Enable, Pin 19 is being driven by U15 which has the rolled off square wave with the ringing at the bottom of the trace.

So data is being transfered across U2, but the timing due to the distorted waveform from U15 may be messing up the data selection being transfered.

Hopefully this makes sense!

Anyway, I am going to see if I can discover what is rolling off the U15 signals.

I really think that U2 is working as it should be, but may be putting bad data out on the data lines.

I have the diodes back in place and the board de-fluxed and looking good. Also have reseated the original CPU and everything is back to were we started.

George (just got your last post, will look the diode connections to see if mine is the same! I have two scopes, an HP 1725A Analog, and a TEK 2440 Digital. Both are dual channel.)

MarkL · « **Reply #42 on:** July 27, 2014, 05:42:06 pm »

U15 output pin 12 (driving U2 Enable) could be an interesting investigation. It looks ok on my 8116A, attached. And my U15 pin 6 has the same fall and rise shape as my pin 12.

You had an earlier trace in post #26 that showed pin 6 has a very slow rise. I think you're saying pin 12 looks like this too. If it's on both output pins, perhaps U15 is ill? Are the pullups R19 and R20 ok (seems like a long shot they'd both be bad)? Take a look at the power and ground pins on U15 with the scope. Anything weird?

You have a lot of ringing on the falling edge on all your screen captures. I was chalking that up to a long ground lead on your probe. Reduce your ground lead length and try to use the ground right on the chip you're probing to see if it's an artifact or really there.

MarkL · « **Reply #43 on:** July 27, 2014, 07:05:21 pm »

Speaking of probes, are you using a 10x probe to look at these signals? If you're not, one possible reason you're seeing such a slow rise time is that you're loading down the open collector outputs with a lot of capacitance.

MarkL · « **Reply #44 on:** July 27, 2014, 07:54:18 pm »

If you feel so inclined, here's a way to check U2. It's not the greatest, but it will find any major faults.

Because U2 is a bidirectional transceiver, no matter which way it's driving, the input should always equal the output while nEnable is low. And because we know exactly when nEnable is low since it's just ~E (a stable clock), we can subtract input from output in this known window and it should be pretty close to 0V.

Here's how you can do this on your 2-ch scope (all done in normal, non-free run mode):

Set up the external trigger input to trigger on the falling edge of U2 nEnable pin 19 (which is ~E from U15 pin 12). Also probe it with Ch1 so you can observe it at the same time. Use the vertical cursors to mark the window where nEnable is low. This is the window where input should equal output. See U2_pin19.png.

Next, you can optionally probe the U2 Direction pin 1 (which is R/nW from the CPU) on Ch1. It should look like U2_pin1.png, but we saw before it wasn't changing on your unit.

Now set up the scope to display Ch1 minus Ch2 and turn on display persistence so you don't miss any intermittents. Attach Ch1 to U2 pin 2 and Ch2 to pin 18. This is one of eight data paths through the transceiver. I've attached photos of what the scope channels look like individually U2_pin2_pin18.png, and with subtract turned on U2_pin2_minus_pin18.png.)

Between the cursors is where you should look for compliance. At the beginning, signals are still settling and they could be anything. But by the end at the right-hand cursor, everything should have settled down and the signal should be around zero volts. If something is stuck high or low in either direction it should be very obvious as a positive or negative trace.

Check the other 7 transceiver pairs: pins 3-17, 4-16, 5-15, 6-14, 7-13, 8-12, 9-11.

George_Race · « **Reply #45 on:** July 27, 2014, 09:07:14 pm »

Hi Mark:

Putting the probe on 10X and using the short probe GND wire, my U15 pin 6 & 12 look exactly like yours! So much for that self created problem!

On U2, I am going to take a look and see if I can follow your procedure. Looks easy enough.

In case no one has every told you, you are a very good mentor/teacher!

Do appreciate all your time and "hand holding"! I am 79 years young and still learning!

Incidentially, will have an HP Signature Analyzer next week, it is on the way. That may be how this one gets fixed. I see another steep learning curve in the future!

George

MarkL · « **Reply #46 on:** July 27, 2014, 11:19:13 pm »

Hi George,

You're welcome and thanks for the compliment! I've done engineering roles in both.

I'm always up for a troubleshooting challenge. It was clear from your first post you were familiar with the equipment and ready to tackle a repair, and IT WASN'T A POWER SUPPLY PROBLEM. Sorry if I offend anyone out there, but power supply problems are boring.

You can't help to learn something by diving into these old repair manuals that provide detailed theory of operation along with the schematics. Today's service manuals of "If Error 123 is Displayed, Replace the Main Board" just doesn't do it for me. I usually just send it off and let them do it.

My signature analyzer should be here on Tuesday. I have nothing broken, so I'll probably just poke around my 8116A since the cover is already off. Never needed one or used one. We'll see...

George_Race · « **Reply #47 on:** July 28, 2014, 12:37:55 am »

Yes Mark, I am always up for a challenge, but I must admit that this one has turned out to be a lot more complex than I expected, but that is the challenge, and I do need a function generator. This one looks like new, but obviously has a bit of a problem.

On the analyzer, I too am looking forward to getting it in hand and seeing what it does. In reading through the troubleshooting on the 8116, there are a lot of tests just on the processor board. And then looking at the changes log, at the end of the file, there is going to be a lot of signatures that are incorrect because some part has been changed or removed in one of the versions. So now knowing what updates have been done is going to be another challenge to keep up with.

I wish that I had a complete accurate schematic diagram. I have gone through the changes list, one by one, and marked or printed out the change sheets pertaining to my processor board. But still do not have a complete version diagram of my particular board. It seems to have bits and pieces of several updates and mods that were probably added in production over the years it was manufactured.

I would think that somewhere there is a complete correct schematic and parts layout file for this particular processor board, but I can't seem to find it anywhere.

If you have any resources for manuals, here is what I am looking for. Microprocessor Circuit Board 08116-66503 E-2317 And it was built in Germany.

Would love to find a manual in PDF that encompasses that particular Processor Board.

Guess it is about time to call it a night. Will chat again soon hopefully,

George

MarkL · « **Reply #48 on:** July 28, 2014, 01:45:57 am »

I have a paper copy of the service manual and it's the same as the one on-line. For early models like yours, I agree the information is scattered and extremely inconvenient.

I think the manual part number you want is 08116-90001 E1182. That seems to be the earliest printing in 1982.

This one on ebay may be what you want (paper copy). Read the paragraph in the third photo about the serial numbers to which it applies:

http://www.ebay.com/itm/251597762190

I think what it's saying is that instead of "Backdating", the change section is moving forward in time. The manual starts with full information up to serial number 2334G02896 and then there's a section of changes after that. At least that's my interpretation.

Let's hope the signature analyzer can make quick work of this. But until then if you still want to try other testing I'm game for it.

George_Race · « **Reply #49 on:** July 28, 2014, 04:49:42 pm »

Hi Mark:
Tried to do the U2 dual trace thing but so far cannot get it to work the way your pictures show.

I use external sync to channel 1 from pin 19 of U2. I then probe ch-1 Pin 2 and ch-2 pin 18. Setting are for CH-1 invert CH-2 add, should result in a base line as the two cancel common waveforms. (Should be the same process as Subtract which I don't have as an option) No matter what I do it does not what to sync anything on the screen.

The same process, using the calibrator, results in almost a perfect flat line. But maybe that is different in some way. Talking about the ch-1 invert and ch-2 add settings.

If I external sync ch-1 and look at pin 19 with ch-1 probe it locks right into a nice square wave with just a very slight roll off, like your picture shows.

Found out this morning that my analyzer will not be here until probably Friday by UPS.

So what am I doing incorrectly? Must be something!\
George

idpromnut · « **Reply #50 on:** July 28, 2014, 06:09:27 pm »

Having a 8116A myself (but it has a different front panel, I will need to throw a photo of mine up), I am interested in the inner workings of this beast

I am following along at home, so if you need me to check anything, just toss me a request

George_Race · « **Reply #51 on:** July 28, 2014, 07:19:58 pm »

Thanks for the offer, not sure at this time what you could do to help. As I am sure you already know, I am working with Mark to get to the bottom of the problem my 8116A is having.

How is your front panel different, I did not realize they made different models, physically, of the 8116A.

When you get a chance, a picture would be nice to see.

I am really enjoying trying to find the problem with this one. Hopefully one of these days it will spring to life!

George

MarkL · « **Reply #52 on:** July 28, 2014, 07:22:00 pm »

I'm a little in the dark about the 2440 since I can't find an operations manual for it (only the service manual plus pictures from ebay).

It sounds like the scope is not triggering on "Ext Trig 1". With "Ext Trig 1" connected to pin 19 of U2, and Ch1 and Ch2 connected to nothing, is the "Trig'd" light on? It should be. And if you remove the signal from "Ext Trig 1" does "Trig'd" go out? Make sure you have the trigger source set to the external trigger input and levels set correctly.

To set external trigger in the service manual it says:
Select TRIGGER SOURCE and push the EXT menu button. Set A EXT SOURCE 1|2 to 1

The trigger level should be around 1.4V for TTL, and DC coupled. And not using "AUTO LEVEL", if the 2440 has that.

And, yes, "Add/Invert" is the same as subtract.

And a verification: If "Trig'd" is on, and with Add/Invert on, connect Ch1 to pin 19 (and Ch2 to nothing). You should get the square wave. Now disconnect Ch1 and connect Ch2 to pin 19. It should be a mirror of the signal since it's inverted. Now connect them both to pin 19. It should be a flat line. If you turn off Invert but leave Add enabled, the signal should be doubled.

Does this help? If everything is triggering properly, a non-functioning U2 would give you seemingly random traces (meaning input is not equal to output). It could also be something else interfering with the bus on the other side of U2, but one step at a time...

And, thank you, idpromnut. What vintage unit do you have? Your front panel is probably different because it does not have burst option 001.

idpromnut · « **Reply #53 on:** July 28, 2014, 07:25:26 pm »

Yes, I noted that there are fewer buttons on the front panel of my unit, and yes, it is a version without the burst option. I will snap a couple of pics tonight and post 'em (along with the year).

idpromnut · « **Reply #54 on:** July 28, 2014, 10:02:09 pm »

As promised, some vintage p0rn circa the 16th week 1988, built in America:

George_Race · « **Reply #55 on:** July 28, 2014, 11:08:51 pm »

Hi there idpromnut:

Interesting user name! Back many years ago, when the FCC decided that auto CW ID was the newest thing in commercial radio, I designed, built, and sold a bunch of auto ID units for business band radios. And I even designed and built a Prom Burner to program the call sign into the chip. That is a lot of years ago and I still have the Prom Burner, and about 40 finished copies of the complete circuit board just waiting for the prom to be burnt, and installed in a very nice silk screened panel case. Have not had the heart to just throw them away! I even hand etched the circuit boards! Was the first on the market, but it only took about a year before the major names in radio come out with their own versions and my initial design went by the way side very quickly. But I started with a production run of 100 units and think that I sold about 60 of them.

On your 8116A, I did not think about the Burst Option making it physically different. I really wanted that feature and went looking for one with it on. Nice pictures a very nice clean looking instrument.

Mark, will try the U2 test using Pin 19 with external trigger and both probes, just to see if I can get the flat line there as well. But as I indicated, that scheme works perfectly on the built in calibrator, so I do believe that I have all the setting correct in the scope, just as you have outlined. Will do some more test and get back to you.

If you would like the operator manual for the TEK 2440 I can send you an indexed scanned PDF version. It comes with a 4 volume set of manuals, number one being the operators manual. Or if you have a need, I can forward all 4 volumes of the documents. It is a pretty nice digital scope, and you can pick one up for a really reasonable price on eBay. As I recall, it was about $10K new a few years back.

Don't know if you may be interested, but I found a really great "paper" on how signature analysis works, and full details on using the 5004A in a lot of examples from the 70's/80's. The best explanation I have seen, but of course I am a very green novice on signature analysis. Soon to become a lot more proficient, or at least so I hope.

Guess that is about it for this time around,

George

idpromnut · « **Reply #56 on:** July 29, 2014, 12:54:37 am »

@George_Race: thanks! I actually encountered "IDPROM"s when working with some old Sun workstation equipment years ago and ended up manually poking bytes into them to revive a couple of dead ones.

Indeed, I had not heard of signature analysis before this thread, neat read!

MarkL · « **Reply #57 on:** July 29, 2014, 03:38:42 pm »

Hey George,

We never looked at the data bus on the *other* side of the transceiver from the CPU. We've only looked at the CPU data bus and the latch bus.

Take a minute to probe D7 through D0 with just regular triggering and the unit in normal (non-free run) mode to make sure there's nothing obvious stuck high or low. That side is on U2 pins 9 8 7 6 5 4 3 2.

If there is, we can forget the input/output test and start hunting. (Any stuck bits would show up on the input/output test too, and is likely what you're seeing if you're sure you have the triggering right.) There's a lot of chips that sit on that bus, about 11 in your version, so it could be an interesting hunting expedition.

If nothing is stuck, it's still worth doing the input/output comparison on U2.

MarkL · « **Reply #58 on:** July 30, 2014, 12:10:46 am »

On the 2440 User Manual, that would be great if you want to PM it to me, or put it somewhere for all to share. It might come in handy so I know what capabilities we have available for further debugging.

You could also consider submitting your scan to an archive site like http://bama.edebris.com/manuals/. They only have the service manual.

It looks like a nice scope with a lot of features for its time. Do you happen to have the Word Recognizer probe?

George_Race · « **Reply #59 on:** July 30, 2014, 01:10:40 am »

Hi Mark:
Nope, nothing is being held high or low on the data out side of U2. It is on a big data bus with a bunch of chips, all of which have the same data stream, just a mixed up mess of stuff that you can't lock on to with the scope.

I have gone chip by chip all over the board. When I find something either high or low I check the schematic to see why. So far nothing had jumped off the board at me. I have a lot of hours into this thing, probably should have spent another couple of hundred and bought one that was working. Gosh, then I would never have had this experience of trying to find the problem in this one. That is really the part of the process that I like. But sure would like to make a breakthrough one of these days. And on top of that, I would not have had the opportunity to meet you along the way. And I would consider that a big loss!

I looked at the TEK 6407 and did a lot of reading about it and it's use. From what i read, it is one great big ball of wires, and the end results are nothing like having an HP Signature Analyzer. From what I have read, I don't think it really went over very well with the service techs.

George

MarkL · « **Reply #60 on:** July 30, 2014, 02:03:38 am »

Quote from: George_Race on July 30, 2014, 01:10:40 am

I looked at the TEK 6407 and did a lot of reading about it and it's use. From what i read, it is one great big ball of wires, and the end results are nothing like having an HP Signature Analyzer. From what I have read, I don't think it really went over very well with the service techs.

Got the manual, thanks.

I have a 6407 for my Tek 2465 (analog) scope. You're right, they don't compare to the signature analyzer, or really to a full logic analyzer. They're good if you don't have those and you've managed to hone the problem down to an exact single shot condition you want to trigger on. That's rare. I think I used mine 2 or 3 times over the 10 years when the 2465 was my main scope. Just wondering if that was in your arsenal for debugging.

As I recall, I was in our local Tektronix sales office and I mentioned the 6407 during some small-talk. The sales engineer later came back with a bag that had one in it with all the grabbers and said, "Here, take it." I guess it wasn't the great accessory they thought it would be.

MarkL · « **Reply #61 on:** July 30, 2014, 03:44:45 pm »

I think looking at every chip on the board for high/low/signal is only going to build frustration.

There may be other problems you might find with that method, but we need to get the CPU executing code first. Your earliest observation was that the address lines are clean square waves of halving frequencies all the way up to A15. This indicates the CPU is incrementing through the full address space and not doing anything useful.

There's not many components needed for the CPU to run. It would include the CPU, the ROMs, possibly the external RAM (the CPU has some internal RAM), and a little bit of glue logic. In the 8116A, there's also transceiver U2 that sits between the CPU and ROMs, so it's in the critical loop too. We need to first make sure those are all working as best we can. You've tried a new CPU, and the signature analyzer will verify the ROMs (although I think they're probably fine, otherwise the CPU would be doing *something*). The external RAM might need a closer look, but the unit is supposed to test it before using it, so it's not a prime suspect at this point.

And then there's other components that are not needed for the CPU to run but they can interfere if they're not staying off the bus. Those may be harder to find since everything's in parallel.

Do you not want to test U2? Was the setup unclear or unsuccessful? Were you able to look at all the pairs?

Side note: I noticed in my 8116A in free-run mode the RPT and OFS indicators are on like yours. Nothing else is on.

George_Race · « **Reply #62 on:** July 30, 2014, 03:58:35 pm »

Hi Mark:

I just got your recent post, and here is my quick reply! (I was in the middle of posing it when your posted your!)

I went back through all of our posts from the begining of the file. Way back in some of the early posts I pointed out that CPU Pin 31, which is D2, was setting high all the time with the other data lines all having a really noisy signal.

I did this because this morning, without any intureptions, I scanned all the data lines on U2 and noticed that Pin 16, D2 was setting high while the other data pins have the noisy signal on each of them.

Now the interesting thing! On U2, Pin 4 which is D2 on the A side of the device has the same noisy signals as all the other A side data pins.

Now that I would think is a problem, U2 must be defective as it's A side and B side are totally different.

U2 pin 16 is connected directly to CPU U1 Pin 31, and I varified it with the ohm meter. Seeing that we have a great looking clock pulse on U2 G Pin 19, my conclusion is that it is that the internal gate system between pin 3 and pin 16 is blown open! The R1 pull up is holding the pin high!

Now to find a 74LS245N! Ebay here I come, again!

What do you think Mike, can it be this easy or have I missed something here?

And Mike, you have been saying you suspect U2 had a problem for some time now! Hopefully you are correct.

George

MarkL · « **Reply #63 on:** July 30, 2014, 04:35:51 pm »

Ah, interesting.

But you had also reported that D2 was showing some pulses in post #19, and explicitly called it out since it was somewhat related to LD2.

I think it's a pretty good bet U2 is dead. But to be sure you need to synchronize your observation to when it's supposed to be enabled. Again, back to the U2 test.

I like to be as sure as I can before pulling chips off a board since there's always a risk of damage. If DIP replacement is no sweat for you, go for it.

It looks like 74LS245 is still widely available, even from major distributors like Mouser and Digikey, for under $1. Why take a chance with some second-hand pull from ebay?

If I had one I'd send it to you, but I only have an HCT version.

George_Race · « **Reply #64 on:** July 30, 2014, 05:01:00 pm »

The U2 test failed on the suspected open pair.

Got that all figured out this morning as well. In compare mode the scope adds a third trace between A & B that shows the results. (Ext trigger CH1 & CH1 Invert)

All on clock pin 19 shows straight line!

I am bothered by the fact that U2 pairs are not a straight line like it looks on Pin 19. There appears to be random noise on the Data Lines and the input/output does not cancel all the noise. Maybe this is normal and it would interesting to have you do the same test on your U2 and report the findings.

I am going to take some quick pictures to show you the results I am talking about. Will post them here in a bit.

I do think we are finally making progress and I have learned even more! The input output comparison with the 2 channel scope is a new trick to add to my old bag of tricks! Thanks for that one.

On the parts, for less than $10 I have 4 chips and 20 low profile socket adapters coming. Chips are NOS so are not pulls!

George

George_Race · « **Reply #65 on:** July 30, 2014, 05:45:26 pm »

Me again Mark, here is what is going on with U2:

This is the clock comparison:
The clock looks really rolled off due to the fact that I parelled the two inputs probes and the Ext Trigger. Kind of loaded down the rise time!

Is a nice 1 MHz Clock. The ringing is from my long scope ground lead!

This is how a good pair compares:

This is how the bad pair compares:

This is the second set of traces that show the proper timing of the pins!
Thanks to Mike pointing out the error of my ways!

George

MarkL · « **Reply #66 on:** July 30, 2014, 05:58:03 pm »

Yeah, that's quite a bit of capacitance on the clock, but I get your point.

But that is an unreal amount of noise on the data lines! No, my U2 looks nothing like that.

Something is going crazy on that side of the data bus! Do they all look like that?

MarkL · « **Reply #67 on:** July 30, 2014, 06:24:11 pm »

Wait a minute... Your second capture shows it on both sides of U2. So it *is* on both data buses.

Do they all look like this now? You had a couple shots from early on and this noise wasn't present (before you tried the new CPU).

And it's common mode noise because it almost cancels itself out. It's like U2 is oscillating.

What does the U2 pin 1 look like?

Is there anything odd on U2's power pins, 10 and 20?

Does the noise look different if you look at it with only one of the probes?

Do you have averaging turned on? (Needs to be off.)

George_Race · « **Reply #68 on:** July 30, 2014, 08:26:29 pm »

Yes they all look like that!

The scope traces have been changed! Shows just how ease it is for a novice digital scope user to be doing things incorrectly. Thanks Mark for setting me straight with your observation and questioning of my traces.

Another observation. In the Troubleshooting Section it says for free run you need to move the jumper to the free run position and open A2W2 to force NMI High, and then short Reset to Ground.

I do not have an A2W2 jumper, but do have a W2 jumper on the board.
Do I need to open my W2 as part of the free run process?

One side goes to Pin 12 of U28, the other to U10 & U11 Pins 18. Both Pin 18's are marked on the schematic to go to U28 Pin 1. So in reality, the jumper W2 ties U28 Pin 12 to U28 Pin1 which in turn is connected to U10 & U11 Pins 18.

From what I can see, U10 & U11 are RAM. U28 is an added Xistor Quad PNP package.

W2 breaks the connection between U28 Pins 1 & 12. (Not In Any Schematic)
I don't see what this has to do with Forcing NMI High.

My processor board is a 66506. But, it has many of the changes that appear on processor board 66513.

All of this above I have put together from Section B of the Manual, Backdating.

There are several Backdating pages that apply to my processor board. Here is a list of the PAGE NUMBERS that apply. If you have the 66506 board you should print them out and keep with your Processor 3A Schematic sheet.

B-29
B-30
B-45
B-46
B-47

Hopefully this will help others in the future who are trying to trouble shoot their Function Generator.

I guess the next step will be to replace the defective chip U2 and get back here with the results in a few days.

George

MarkL · « **Reply #69 on:** July 30, 2014, 11:32:40 pm »

I don't think it's coming from the CPU since it's happening on both sides of U2. U2 is providing digital isolation between the two buses, and your signals almost cancel each other out in the analog domain.

Free run mode disables U2 via pulling nEnable (pin 19) high. When you say the noise disappears, do you mean on both sides of U2?

Averaging can make unsynchronized waveforms look pretty strange depending where the transitions are occurring, although admittedly I don't think I've ever seen that kind of result. Are you using averaging?

What acquisition mode have you selected? The signals themselves *are* changing during those "noise" periods, but not nearly at the frequency being shown. Maybe there's something I'm overlooking about the 2440 acquisition modes that's making it look like that.

Does it look the same if you clear the trace and do a single-shot acquisition?

Just trying to figure out if the signal is really doing this. It's quite bizarre. I'll look through the 2440 manual. And there's always the analog scope.

The A2W2 jumper would be on the A2 board. And the signature analysis needs it to be out otherwise the numbers might not match or you might have unstable numbers on the analyzer.

MarkL · « **Reply #70 on:** July 31, 2014, 01:05:19 am »

Hey George,

Am I seeing it right that you're at 5ms/div?

If so, that's way too slow. You're undersampling. That would explain a lot.

You got a good waveform in #1 because of aliasing.

George_Race · « **Reply #71 on:** July 31, 2014, 01:24:10 pm »

As always Mark, thanks for helping me to better understand what I am doing!

The three previous trace pictures have been changed, I think you will agree they are finally correct.

The problem is still an open pin 16, as the third trace shows.

What do you think Mark, do I have the traces correct this time?

Sure do appreciate you holding my hand throughout this process!

George

MarkL · « **Reply #72 on:** July 31, 2014, 07:24:58 pm »

The traces are clean now and the third screen shot clearly shows the input is not equal to the output. This is progress.

On the third shot I notice that the Ch2 voltage level is only half of what it should be during the last enable pulse. Which pin is Ch2 connected to? It looks like it's struggling get to a logic low and not making it to the threshold (0.8V). It might be why Ch1 is still a logic high during that interval, but we don't know which direction the transceiver is driving (that'll be next).

If you can manage to capture the level of U2 Direction (pin 1) during one of those half-voltage events that would be useful. Leave Ch2 where it is, and still using the Ext 1 trigger, probe pin 1 with Ch1 and just keep hitting the single shot button until you get one. You wouldn't need the Add/Invert for that. I think we're done with the Add/Invert trace now that we've zeroed in on the bad bit.

And a note: For debugging logic, you should use DC coupling on both Ch1 and Ch2 so it's clear what the absolute voltage levels are in the absence of any transitions. Right now you have AC coupling on Ch2 (the "~" symbol). And I think you're not triggering on the Ext1 input in the third shot, although you did manage to capture the problem which is fine.

PS - It's too bad you took down the "noisy traces"! Those were great examples of what can happen with aliasing, and the aliased enable signal in particular was perfect. It totally fooled me!

Also it's Mark, but if Mike wants to join the party, come on in!

George_Race · « **Reply #73 on:** July 31, 2014, 07:50:48 pm »

Mark, Mark, Mark! Sorry about calling your Mike! I hate it when someone does that! And I sure did.

I still have the other pictures in the file, do you want me to forward them to you?

This is the very first time that I have put the digital scope to good use, so I just have never learned to do things properly, kind of hit and miss up to now. So I don't always get all the parameters correct. But thanks to a good teacher, MARK, I am learning. And my nose is in the users manual as well!

Got the signature analyzer today. That is a really neat instrument. Am in the process of going down the chips on the processor board. So far all the signatures are exactly as prescribed in the lists.

I wont be in trouble until I start doing signatures on the chips that have been replaced by others on the board. But the Backdating sheets show the new signatures, so will see what happens when I get that far.

Now to get back to playing with the new tool, looking for signatures!

George

MarkL · « **Reply #74 on:** July 31, 2014, 08:56:24 pm »

Good luck with the new analyzer! Let us all know what you find.

Seems I still have your screen shots in my browser's back button. I've re-attached them below so others can understand the previous comments.

For those not wanting to go back and dig: These are all under-sampled, aliased traces. The actual frequency of the first signal is 1MHz. The "noise" in the second two are a result of sampling across multiple occurrences of the waveform where the waveform was changing from cycle to cycle.

Put another way, the scope's sample rate was sufficiently slow that it was sampling successive points from different cycles of the waveform.

George_Race · « **Reply #75 on:** July 31, 2014, 09:19:52 pm »

Glad you found the pictures Mark, and a nice explanation of what was happening.

Well the Signature Analysis of the Microprocessor Board is done.
Here is the results:

Signatures for Address Drivers and Decoders: All Correct
ROM Signatures: All Correct
Keyboard Signatures: All Correct

And for those looking in, my board has the set of 6 ROM's.
I used Table 10.7-5 ROM signatures 08116-1002X/310X Series
for the Signatures.
It is from BackDating Page B-49

I thought that Signature Analysis on an HP instrument would clearly show where the problem being experienced was, right down to the chip. But in this case that is not the way it turned out. It still took digging in and looking at the Data Buss to discover where the difficulty was.

Mark, how come there is no signature analysis for all the other chips on the board? Must be some limitations depending on the type of chip and how it is used in the circuit. Can you please fill us in?

As soon as I get the new chip installed I will get back with more information on how the repair is coming along.

George

MarkL · « **Reply #76 on:** August 01, 2014, 01:49:06 am »

Sorry the signature analyzer wasn't more helpful for you.

No surprise, though, since that's what others have said about the signature analyzer - Sometimes you get lucky with it, but most of the time you have to dig in anyway.

But it did confirm that side of the data bus is ok since all the ROMs read out fine. So, it can help by at least verifying what pieces are working.

Quote

Mark, how come there is no signature analysis for all the other chips on the board? Must be some limitations depending on the type of chip and how it is used in the circuit. Can you please fill us in?

Who knows for sure, but there's a very large number instrument setups and moving around of probes they would have to document to be able to get meaningful signatures on every pin of every chip. And signatures depend on consistently repeating patterns of bits so it might not even be possible in every case.

They probably could have done more, but it looks like they chose to cover just the more insidious failures, for instance a bad byte in a ROM.

It's also why they spend a significant amount of time writing the theory of operation sections so you can understand how it's *supposed* to work and go from there.

George_Race · « **Reply #77 on:** August 03, 2014, 12:11:14 am »

Today the new 20 pin Socket Adaptors arrived. Removed the defective 74LS245N (U2), and replaced it with the Socket Adaptor.

Had hoped that the replacement 74LS245N would be here today too, but no such luck. Hopefully it will be here Monday and I can plug it in and see what happens.

George

George_Race · « **Reply #78 on:** August 04, 2014, 09:50:37 pm »

The new IC arrived and has been installed:

when I hit the on switch, it went into self test and here is the result.

Just sitting there putting out a perfect 1 MHz Sine Wave!

I am very pleased, especially with MarkL for all the hand holding he did as I worked through learning how to properly use a Digital Scope. It is interesting that very early on in the process he already knew that U2 was probably causing all the difficulty. Hats off to MarkL! I really do appreciate all you have done to help me with this repair.

Normally I buy, repair, and resell on eBay, but not this time. This one is a keeper. Have been wanting a nice Function Generator for some time, and this has turned out to be a really nice working and looking instrument for the work bench. Next I am going to go through the Performance Testing section of the manual. If needed I will continue with adjustment procedures, where necessary, just to make sure this "Old Girl" meets it's original specifications.

Everything seems to work, but I do need to sit down and go through the setup procedures for the various modes. All the waveforms coming out really look great, frequency wise, it is very close all across the range up to over 50 MHz.

I can hardly wait to take a look at the output on the Spectrum Analyzer to see just how good it really is. I am very pleased.

There is one last question that hopefully MarkL can answer for me. I can't seem to find an answer in the users manual, but maybe I have not looked in the correct place as of yet.

When I press and hold the LCL button, the display shows A 16. Just what does that mean?

Thanks for all the comments and I hope you all enjoyed being along on the journey, it has been fun.

Take care and 73,
George - WB8BGY

dave_k · « **Reply #79 on:** August 04, 2014, 10:04:08 pm »

Hi George,

Pressing the LCL button shows the GPIB address in decimal.
In your case the address is 16.
Glad to read your HP works again - great job!

MarkL · « **Reply #80 on:** August 04, 2014, 10:11:11 pm »

Hey, that's great George! Glad it's working now!

Quote from: George_Race on August 04, 2014, 09:50:37 pm

There is one last question that hopefully MarkL can answer for me. I can't seem to find an answer in the users manual, but maybe I have not looked in the correct place as of yet.

When I press and hold the LCL button, the display shows A 16. Just what does that mean?

That's its GPIB address, as set by the DIP switches on the back. 16 is the default.

One word of warning on adjustments - I would recommend doing the performance check before trying to adjust *anything*. If it passes the performance check let it go. I went down the road of doing a calibration on my unit and it took me 2 days to get it back. Some additional detail:

https://www.eevblog.com/forum/testgear/hp8116a-manual-problem/msg388727

Glad to help - Enjoy your func gen!

George_Race · « **Reply #81 on:** August 04, 2014, 11:29:11 pm »

Thanks for all the comments, yes I am going to enjoy it a lot. It will really come in handy.

MarkL, I totally agree, if it is even close to being where it belongs, I will not change anything. I don't need 2 days of aggrevation over a few Hertz or MiliVolts!

And lastly, it seems that I always have one more thing that I need help with!

There was not a battery in the unit when I got it. My question is which battery do I need, NiCAD or Lithium?

BD 61 on page B43 talks about serial numbers and a change that has to be made. I don't know how that applies to my unit.

My serial number is: 2334G02413

My Microprocesor board is the 08116-66503, but the circuitry that I have on the board is exactly like Figure B-15.08116-66513: U28 schematic that is shown on Backdating page B-47 in the top diagram.

Can someone tell me which one I need, and if possible a replacement part number. I am aware of the Panasonic BR 2/3 being used for some replacements, but don't know if that is the corrrect replacement battery for my unit..

Thanks,
George

MarkL · « **Reply #82 on:** August 05, 2014, 01:33:16 am »

Serial #2334G02413 is old enough to have the NiCad. See my previous post on the battery type here:

https://www.eevblog.com/forum/testgear/hp8116a-manual-problem/msg423568/#msg423568

I didn't see anyone post an easier to get cross reference, or confirm any of the three part numbers mentioned were ok or available.

HP says the original is 2.5V, so it must be 2 NiCads in series. One suggestion would be to get 2 of these with the PCB pins, solder them together end-to-end, and shrink wrap them:

http://store.batteryspecialists.com/nicd-nimh-1-3aa.html

There might also be a battery assembly company that could make you one, but it's probably going to cost a bundle.

You could also get a generic 2 cell pack, or install a 2xAA holder and put some regular NiCads in it as other have mentioned.

George_Race · « **Reply #83 on:** August 06, 2014, 04:26:07 pm »

The project is finally finished.
Installed the batteries and everyting is working as it should.

There was not enough room to install a battery holder for the new NiCAD's so I simply soldered them in place and tied them down with a tiewrap.

I purchased the batteries for a total of $2.73 at my local Batteries Plus Bulbs store. Part numbers are: NUN1100-AAF - AA 1.2V NICD FLAT

Now when I do a setup, and turn off the instrument, it starts back up with all the same setting as before I turned it off.

MarkL, I spent a lot of time last evening going through the performance testing, page after page! Did not have some of the equipment needed, but managed to do all the tests and am very pleased with the overall results. Throughout the full range of Frequencies and Amplitueds, all are within +- 5% to 7% of indicated values. The scans on my HP-8568 look very close to the pictures printed in the Testing and Performance section of the Manual.

This turns out to be one of the best $130 equipment investment that I have ever made. I am most pleased with the overall outcome, and I learned a bunch about using a Digital Scope, thanks to your help.

Here is the finished project.

A big thanks to the group on EEV, and especially you Mark for seeing me through the project.

All that I need to make this almost like brand new is the front top plastic trim piece, that snaps into place, and two of the bottom snap in feet and the bail stand. Boy, what would I do without eBay! They are there!

George

George_Race · « **Reply #84 on:** August 08, 2014, 12:40:49 am »

Got the bottom feet and the 2 bail pieces on the way from eBay.

I cannot find the plastic strip for the top front of the instrument anywhere. Even searched by the HP part numbers, no luck.

Does someone on here, by chance, have one just laying around begging to be used?

If you do, please let me know. I will be glad to pay a reasonable price and shipping cost to get it.

Thanks,
George

pelule · « **Reply #85 on:** November 29, 2015, 10:31:22 pm »

I need to repair one of my HP 8116A (option 001).
Fault is definitively on the CPU/A3 board, rev 66503 (2440), placeplan attached.
Checked all voltages and replaced A3 with another A3 from a 2nd 8116A - system works fine then.
Failure:
all displays/LEDs, controlled via the Latches Data Bus do not operate correct.
The ICM7218A controlled 7-segments and LEDs are dark, the LS374 controlled LEDs are random.
As long as a key is pushed (for example scanning down the frequency) the displays show, a bit dim, the correct displays, as soon no key is pushed, the display goes dark/random again.
Thus no problem on ROM, RAM, CPU. No akku issues for the RAM.
It must be a problem on the data bus / latched data bus path or the control signals for that.
Checked with HP 5005B signature analyser. All signatures are ok (not a big surprise as there are none given for the Latched Data Bus area).
Replaced/tested U25 (245), U2/U26 (244), U16/U23/U24 (374) and U22 (ICM7218A).
Control signals (LB, LATCH1, LATCH2, /WRITE, /READ, /MODE) seem to be fine also.

Any idea for the problem is welcome.
Really stuck, that 8116A drives me crazy.

MarkL · « **Reply #86 on:** November 30, 2015, 03:23:12 am »

Very strange. Does the unit output the right waveforms?

You are saying that ALL signature tests passed: tables 10.7-3, 10.7-5, and 10.7-6?

If you hold down a key, are all the LEDs then correct too?

If you hold down a key on boot, do you get the key stuck indication with normal display brightness?

Can you include a photo of the front panel so we can see the random LEDs that are on? Are the same LEDs on each time? Do you get the "all LEDs on" test at boot?

If you have a working second A3 board, do you have a fully working second 8116A to compare against?

For next steps: Do you have oscilloscope? How about a logic analyzer?

pelule · « **Reply #87 on:** November 30, 2015, 10:59:19 pm »

I try to answer your question as detailed as possible. But it's not easy to explain dynamic processes.
Hope your are able to follow, what I did/tested already.

Quote

Very strange. Does the unit output the right waveforms?

In deed, it's quite strange. All output (incl. sweep) are correct with both A3 board, just hard to control with the bad one.

First I checked the supply voltages. Next I conected the good A3 board and checked the functions.
Than I used the bad A3 board and (tried) to check the functions again.
Thus my conlusion: problem is located on the CPU/A3 board on the display section.

Quote

You are saying that ALL signature tests passed: tables 10.7-3, 10.7-5, and 10.7-6?

Yes correct.
Table 10.7-3. Signatures for Address Drivers and Decoders - all correct
Note: signature U10(

= shows UUUU, printed is UUUH. This is A0 @ U10/RAM, it is the same signal as U3(18) A0 @ 74LS244N, thus UUUU must be correct (doc error?)
Table 10.7-5. ROM Signatures (for 08116-1000X Series) - all correct
Table 10.7-6. Keyboard signatures - all correct (now)
Just as note: found an issue with [LCL] button, I have repaired already. An "i..t" had glued a brocken part of the button, that glued also the metal connectors.

Quote

If you hold down a key on boot, do you get the key stuck indication with normal display brightness?

I get the "stuck" display, but dim (see picture)

Quote

If you hold down a key, are all the LEDs then correct too?

Not at all keys (depends on function)
if I press [Auto], all seems to be ok, just a dim display (see picture).
At some buttons pressed, display is correct but only ~1s
If you scan frequency up or down, all seems to be ok, just dim.
So my conclsion:
- during key scanning the display data is frequently updated, thus you get a dim, but visible display.
- if no key scanning is processed, the display data is not continously updated, thus the display is deleted/cleared.

Quote

Can you include a photo of the front panel so we can see the random LEDs that are on? Are the same LEDs on each time? Do you get the "all LEDs on" test at boot?

I added some pictures for good & bad A3 board. Showing setup, Stuck-Key-State, All-On-State and Ready-State.
Note: as the accu is not present, the bad board shows first Err1-state befor going to "ready" state. Bad seems not to show All-On-State.

Quote

If you have a working second A3 board, do you have a fully working second 8116A to compare against?

Yes, I have a 2nd fully working tool, but does not have option 001 (sweep).
But as noted, the "defekt" tool works fine with the "working" A3 board.
As the good A3 boards has different revision (66513), I did not yet test the "defekt" A3 board in the working tool.
Does not give any further information beside an additional confirmation, the error is on the bad A3 board.

Quote

For next steps: Do you have oscilloscope? How about a logic analyzer?

Yes, have all that equipment.
2ch 200 MHz digital scope (RIGOL) & 2ch 500 MHz analog storage scope (TEK)
16ch 150MHz analyser (LAP-C)

I did already many measures.
I check the signal in/out of the various bus driver, the latching of data, as well I recorded and analysed the data & control signals for the ICM.
The signal seem to be ok, the data flow is in line with my expectation of correct control/data of the ICM for required displays.
That let me first think the ICM is defekt and I replaced it with a NOS (in fact I tested now 3).
But that wasn't the cause of problem.
Thus my conclusion is: it is related to the data bus, the latched data bus or the related control signals.
As the display shows in certaint conditions the correct, but dim displays and taking into account, the running program does continously
update of display data (to change display, all data has to be re-written), the dim display may caused by the frequently change between correct display data and wrong/corrupted display data.
This results to a kind of on/off, thus reduced brightness.
So I would assume the display data is time to time presented with wrong timing and/or missing signals/levels.

I assumed a bus-down of one of the "driver" ICs. So I "strategic" replaced the different ICs connected to the Data Bus and the Latched Data Bus (244/245/374).
But the problem persist.
I have soldered sockets for each IC I replaced.
So my next planned step was, to concentrate on just problem after the other, starting with the most simple part of circuit.
First get one of the two 374 latched LEDs operating.
Thus remove all for that function not relevant ICs to make test condition more simple.
Seach for the problem and solve it.
Than do the same with the 2nd 374 latched LED.
Than work on the ICM problem, as is is the most complex part.
I would start with the select signals and timing (74LS138 ICs). As signatures where ok, it may be a timing issue caused by a week FAN-OUT of one of the 74LS138.

Notes on the pictures:
000 shows the used A3 board
001 shows the setup
002 shows keep LCL button pressed during power-on (force stuck key)
003 shows display after LCL release (all-on or Err1)
004 shows ready state
on the bad board the sequence is
first 004a, after ~1s 004b, if [auto] button keept pressed, shows 004c.
this state keeps until [auto] is released, than it goes to state 004b again

Any tip or sugestions is highly welcome.
BR
PeLuLe

pelule · « **Reply #88 on:** November 30, 2015, 11:02:05 pm »

next pictures

pelule · « **Reply #89 on:** November 30, 2015, 11:04:23 pm »

and the next

pelule · « **Reply #90 on:** November 30, 2015, 11:05:53 pm »

and the last ones

free_electron · « **Reply #91 on:** December 01, 2015, 01:19:40 am »

check the circuitry around the battery

the 'dim diplayt' is because the main cpu cannot complete its scan cycle. it keeps getting interrupted by something.

these machines run a timed cycle codebase. if something keeps bombarding the cpu with interrupts you will get this strange dimming effect.

could also be the GPIB controller that is wonky ...

MarkL · « **Reply #92 on:** December 01, 2015, 05:15:51 am »

Thanks for the very detailed information. I'm still looking at it all, but here's a couple of thoughts.

I agree it could be a weak driver. Take a look with your scope at the data and control pins on latch bus components to make sure they are getting to the right levels.

Another way to tackle a problem like this is to set up your scope or logic analyzer to trigger when the problem occurs. Once that's done, you might be able to work your way backwards to the cause.

In this case, the 8 button LEDs that are on from 90deg to DISABLE are all on the DIG0 line. The register that controls DIG0 is the first one written after the ICM7218A is given the DATA COMING command. You could try to set up a trigger for all 1's getting written immediately after DATA COMING, or maybe it's sufficient to just look for all 1's getting written in conjunction with /WRITE=low and MODE=low.

Because the ICM7218A is loaded sequentially, it may also be getting too many or too few write pulses. That's also something you could verify by counting groups of 8 pulses with /WRITE=low and MODE=low before MODE goes high again.

MarkL · « **Reply #93 on:** December 01, 2015, 05:32:16 am »

Quote from: free_electron on December 01, 2015, 01:19:40 am

the 'dim diplayt' is because the main cpu cannot complete its scan cycle. it keeps getting interrupted by something.

these machines run a timed cycle codebase. if something keeps bombarding the cpu with interrupts you will get this strange dimming effect.

could also be the GPIB controller that is wonky ...

The display controller autonomously does the display scan multiplexing without CPU intervention. You load it with 8 bytes of data and off it goes.

I think he's on the right track that it's getting loaded with the right data when a key is held and then it gets clobbered. It's probably all happening in the key poll loop.

MarkL · « **Reply #94 on:** December 01, 2015, 06:15:27 pm »

Attached is a trace of the MODE and /WRITE lines on the ICM7218A. As expected, the mode byte is written, followed by 8 bytes of display data.

This sequence happens *once* when a button is pushed. It does not happen upon release, nor does it happen continuously to keep the display updated (except if auto-vernier is active).

I would suggest looking at MODE and /WRITE to see if you get the above behavior.

From what you're describing, I'd bet the ICM7218A is being written after a button release. If so, find out why the extra writes are happening.

I'm not ignoring the fact that the LS374 LEDs are random, but the above is something that is easy to test and repeatable. The random LEDs likely have the same root problem.

I'm not sure it's significant, but when a button is pushed the CPU appears to go into a tight loop waiting for release. It doesn't even respond to GPIB requests as long as the button is pushed. It's possible on your 8116A, the ICM7218A being written continuously during a button push, which may explain the dimming. A further guess is that the keyboard scan and ICM7218A writes are getting tangled up together.

One caveat is that the above test was done with EPROM firmware version 08116-10018. If your working unit has the same version as the broken one, you can verify MODE and /WRITE behavior on it first.

Also, the RAM error would appear as "E01". I'm not sure why a "1" would appear, except that it's likely related to the display problem at hand.

EDIT: Fix minor ambiguity in EPROM version.

pelule · « **Reply #95 on:** December 01, 2015, 08:26:45 pm »

Hi guys,
thanks a lot for digging into my problem and all the tips to check.

@ free_electron
Sorry, I did not mention, but I checked the circuitry around the (old rotten NiCd) battery and it seems to be ok.
I don't think this may the caused of the issues, as the program continues after RAM pwr test. This old board revision writes some test data to the RAM, switches of the 5V RAM supply for short time and than check, if RAM content has changed (if changed it generates the E01 bat pwr error and than continues).
But I will connect a 3.5V lab-supply for further tests to simulated the NiCd. For security via a silicon diode and active current limit.
When repair is done, I plan to connect a 3V Li-battery (for protection against unwanted charging current via a Germanium diode for the lowest possible drop voltage ~0.3V at the needed RAM standby current. silicon diode at sane condition drops ~0.5V). Or simply use same solution as George_Race (2 standard NiCd accus in series).

@ MarkL
Many great tips. Will need some time to check.

Keep updating here for the progress.

BR
PeLuLe

MarkL · « **Reply #96 on:** December 01, 2015, 09:47:34 pm »

A small update to the button push vs. display update test above...

It appears that not all button pushes result in a single update to the ICM7218A. Examples (not an exhaustive list):

One update: AUTO, LIMIT, COMPL, DISABLE
One or two updates: 90deg, -90deg
NO updates: 1 CYCLE

This makes sense since those buttons which have an LED associated with them need to be updated. 90deg and -90deg are complementary, so it needs to turn one off and the other on (depending on what's already lit). And "1 CYCLE" has no LED, so no update needed.

If the ERROR LED is on, the display gets updated about twice a second, continuously.

I wonder if the display comes on on the broken one if you hold in "1 CYCLE" ? My guess is not, but it would be interesting to know.

I don't think any of this provides clues to the problem. I'm just pointing out that you should use one of the "one update" buttons if you proceed with the MODE + /WRITE testing. That way you know what *should* be happening.

pelule · « **Reply #97 on:** December 01, 2015, 11:56:16 pm »

I prefer to think first and than do the measurement. That I did based on your tips and tried to confirm the thoughts with measurements.

Here some intermediate results and my so far conclusions:
Buttons are not activate any interrupt thus CPU need to poll the buttons.
As system does react on pushed buttons as expected, CPU must operate ccontinously (no stuck or NMI from the HPIB-device).
Thus ROM, RAM and the CPU related busses (address bus, data bus, and bus transceiver) and decoding are ok (signature confirm this).
Conclusion: issue is at the Latched Data Bus area (as thought already).

MarkL correct explained, the 8116A display management.
ICM is setup with single 9 byte shot sequence (see also data sheet ICM7218AI).
The continously multiplexing of the segment LEDs is done by the ICM independant.
The other button LEDs are simple latches, no multiplexing.

A sequence is send only, if the display content has to be changed.

On the 8116A the ICM direct segment controlling is used, nodecoding.
7-segment LEDs are inverted (1 means the segment is off), the decimal point (DP) is non-inverted (1 means the DP is on)
For example the all off sequence is:
   9-Byte sequence = 1x Mode Byte (only upper 4 bits are valid) + 8x display data bytes (8 bit).

   Byte   M/D   Value (hex, binary, meaning of data)
   1   1   FFh = 1x11---- = Data Coming, (Don't Care), No Decoding, Normal Operation
   2   0   7Fh = 01111111 = digit 1 (all off)
   3   0   7Fh = 01111111 = digit 2 (all off)
   4   0   7Fh = 01111111 = digit 3 (all off)
   5   0   7Fh = 01111111 = digit 4 (all off)
   6   0   7Fh = 01111111 = digit 5 (all off)
   7   0   7Fh = 01111111 = digit 6 (all off)
   8   0   7Fh = 01111111 = digit 7 (all off)
   9   0   7Fh = 01111111 = digit 8 (all off)

That sequence I measured with the analyser already.

MODE and /WRITE signal levels are ok and have good shape.
Looks exactly as in MarkL's attached screen, thus I did not attach again.

If a button is pushed (depend on the button) one or more display sequences are generated, exactly as MarkL noted.
Conclusion: display (ICM, button LEDs) are working in principle. But the data is correpted time to time.
This gives the impression of no display or dim display.

So next steps are (as MarkL alreday recommend)
Ignore the 374 latches for the button LEDs and concentrate on the ICM data sequence first to find the error condition, corrupting the ICM data.
It must an incorrect write (may a wrong mode byte or wrong display data).
For example if the "standby" would wrongly activated (just one wrong mode bit) this may cause a "no display".
Thtas what I will measure first (does the ICM multiplex? means is display of by wrong segment data or by standby)
@ MarkL - excellent tips, the button/sequence list will help a lot.
So it's measurements time now.

Keep you informed on my findings/progress.

BR
PeLuLe

pelule · « **Reply #98 on:** December 03, 2015, 08:31:32 pm »

First potential cause found.
Ao measure with the analyser everything on the Latched Data Bus controlling the ICM everything seems fine, data and controle signal seem ok and match with setting of the expected display..
But a more detailed look showed at each new 9 byte sequence after the 1st /WRITE (5us) low pulse (the mode write) at around 74µs later a short just ~20ns low pulse exist. This may caused by the decoder area, but I have to check in detail.
First I will check at the "good" CPU board, if the pulse exist there also.
Secondly I will try to increase the capcitice load at the /WRITE pin (connect a 100nF cap) to get this short pulse removed to see, if it makes any difference.

BR
PeLuLe

MarkL · « **Reply #99 on:** December 03, 2015, 09:16:46 pm »

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

I would check the enable inputs to U17 (LS138) which is driving the /WRITE line. Check that pin 6 is always high, pin 4 always low. The only enable being used is pin 5, so it should be the only pin pulsing the output.

As far as timing goes, the select inputs (pins 1, 2, 3) should be set up before the enable pulse comes along. The sequence should be to set up the select pins first, then pulse the enable low then high. Changing the select inputs while the enable is active can cause unpredictable glitching on any of the output pins. Could be your problem. You can check for this by triggering on /WRITE and looking at the enable and select pins.

U21B drives U17 and is configured as a pass-through buffer. It could also be at fault. Check that each pair of input and outputs match (pins 13+7, 15+5, 17+3). An easy way to do this on your scope is to subtract one channel from the other and probe the input on one channel and the output on the other channel. If the gate is working, you'll always see 0V, except during switching where's there's a short 10 to 20ns of gate delay.

MarkL · « **Reply #100 on:** December 03, 2015, 10:14:29 pm »

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 · « **Reply #101 on:** December 05, 2015, 12:08:40 pm »

Hi MarkL

Quote

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.

Quote

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 · « **Reply #102 on:** December 05, 2015, 05:24:56 pm »

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 · « **Reply #103 on:** December 06, 2015, 08:32:17 pm »

Quote

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.

Quote

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 · « **Reply #104 on:** December 06, 2015, 08:59:24 pm »

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 · « **Reply #105 on:** December 07, 2015, 09:38:17 pm »

Quote

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

Quote

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 · « **Reply #106 on:** December 07, 2015, 09:40:08 pm »

next pictures...

MarkL · « **Reply #107 on:** December 07, 2015, 10:28:19 pm »

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 · « **Reply #108 on:** December 07, 2015, 10:49:31 pm »

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 · « **Reply #109 on:** December 08, 2015, 09:04:20 pm »

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 · « **Reply #110 on:** December 08, 2015, 10:00:50 pm »

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

Quote

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)

Quote

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.

Quote

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 · « **Reply #111 on:** December 11, 2015, 10:12:59 pm »

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.

Quote

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.

Quote

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 · « **Reply #112 on:** December 11, 2015, 11:29:42 pm »

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 · « **Reply #113 on:** December 12, 2015, 12:18:32 am »

Quote

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.

Quote

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


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee