Author Topic: Help with HP 8116A (Read 38332 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.


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

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

Share me