Repair Log: HP 3314A, Part 1

At a recent swap-meet I came across an HP 3314A Programmable Function Generator that was described as non-operational but was physically in good shape.

In my opinion, HP cases make great project boxes (see here, here, and here), and this case looked like it would be an excellent case for a future, yet-to-be-defined project.

And so I made an offer based solely on the idea of scrapping the 3314A's electronics but keeping its case and internal chassis.  The offer was accepted, and the 3314A came home with me.

But after I had returned home, I had second thoughts about my plan to scrap the unit.  Why not try to fix it, if that were possible?

And thus this blog post, which describes my efforts to bring this HP 3314A back to life.

Initial Power-On Error:

The first problem I came across was at power-up -- the unit would cycle through its initial count-down following power-up, and then it would hang.  The count numbers displayed during the Power-up cycle would often also be screwed up.  And at the end of this cycle, sometimes the 3314A would hang with the LED numerical display being blank, and sometimes the display would show Error Codes E13 or E43.

Looking in the manual (section 3-1), Error Code E13 does not exist, and, although Error Code E43 exists, it is an HP-IB Error Code meaning "Invalid Data."  Given that the instrument was not in Remote mode (i.e. HP-IB mode), the display of this last error code could be meaningless and a result of some other error.

Note that immediately following power-up, the unit's 3-digit numerical display should show the following sequential count-down:

999

888

777

666

555

444

333

222

111

000

The video, below, demonstrates the Count-down problem:

You can see from the video that the displays are changing, so the 3314A is attempting this count-down, but the digits of the first counts are screwed up.

But before I go any further...

A quick note on my initial trouble-shooting:

The HP Service Manual (downloadable from the Keysight website: HP 3314A Manuals) recommends trouble-shooting using Signature Analysis.  Unfortunately, I was at my wife's place in Nevada City, CA, at the time of this initial trouble-shooting, and my Signature Analyzer was back at my house in Silicon Valley, CA.

(Plus, the SA unit has been sitting in a box, untested, for at least 20 years (another swap-meet find), and I had no idea if it worked, or not, as I've never had a need to use it!)

So, this initial phase of trouble-shooting was done with a 2-channel oscilloscope...

Probing the Front Panel Assembly:

Because segments of the LED seven-segment displays were either being incorrectly kept off or, alternately, incorrectly illuminated, it made sense to start my trouble-shooting at the Keyboard assembly where the seven-segment displays reside.

But I immediately encountered several issues.  The first issue is that the HP schematic has a number of errors.

The image, below, shows my corrections, in red.  You can see that U1's (74LS273) inputs were incorrectly assigned.  Also, the pin number of the LED displays are incorrect.

Here's a closeup of U1.  Its correct pin number assignments are shown in red:

And here's a closeup of the correct seven-segment display pinout (in red):

(Note that I also corrected the names of the three signals driving the common-cathode pins of these three displays to match the net names assigned to their respective drivers.)

The image below shows the correct pin number (in red) and the associated data bit from the 8-bit bus (in blue) for each segment of the LED.

When count-down sequence first starts, the first count presented on each seven-segment display is '9', and then this number counts down (8, 7, 6, etc.).  The numbers are the same on all three seven-segment displays, so the displayed numbers should be, in sequence, 999, 888, 777, 666, 555, etc.

Thus, the segments of the seven-segment display associated with data-bits DL0, DL1, DL2, and DL3 should be ON for the first count-down digits (9, 8, 7...), but, as you can see in the video, above, they are OFF.  These will later turn ON for lower counts (e.g. 3, 2, 1, 0), but at the start of count-down they are OFF.

The image below shows the problematic segments (highlighted in yellow):

The Keyboard assembly is a multiplexed system with the segments of the seven-segment displays sharing the same "row" signals (as in a row-column matrix) as the other front-panel LEDs.  Thus, probing a segment to see if it is correctly turning on or off can be a bit of a challenge with a two-channel scope, especially with the count-down's count quickly changing as it counts down.

But by observing U1's outputs (the 'LS273) responsible for driving the numerical segments immediately after power-on, it was clear that U1's outputs were not being set to the correct state to drive these segments ON for the first few counts (a U1 output bit must be set LOW to turn ON a segment).

Tracing this failure back...the data at U1's inputs, arriving at the Keyboard from the Controller Board,  was also in the incorrect state for these counts.  Thus, U1 was simply passing on incorrect data from the Controller Board.

So time to move the probing to the Controller Board...

Probing the Controller Board:

At the controller board I started at the processor, looking at its Data Bus while triggering the scope on the rising edge of the clock clocking data into the U1 register on the Keyboard assembly.  This probing showed that the data from the microprocessor that was being written to the Keyboard assembly was also incorrect.

So why was the processor writing incorrect data?  Was it getting bad data from the PROMs (of which there are six)?  Or was RAM bad?  Or was something fighting the bus when the processor was attempting to read or write this data?

Even though I did not have a Signature Analyzer, I decided to invoke one of its tests (SA Test #1, in which switches 1, 2, 7, and 8 are turned ON), because I assumed this test would sequentially count through all of the microprocessor's addresses and I could look for errors either on the Address Bus or on the Data Bus during this time.

Everything was looking good until I got to the CMOS SRAM, U211 and U212 (NEC UPD444/6514 1Kx4 bit CMOS RAM).  The four data I/O pins of U212 had flaky looking levels for some of its read cycles.  Plus, these flaky levels would change with time.  

The image below (lower scope trace) shows the levels one of these pins (pin 11, or I/O4).  U212's outputs are enabled whenever the upper trace is low.

Compared to U212, the I/O pins of U211 looked fine -- it was only U212's four data pins that had the issue.  And these four data bits correspond to the low-order four bits of the Data Bus, which were the problem bits driving the Keyboard's seven-segment displays.

Could a bad U212 be the culprit?  I placed an order of a pair of new NEC UPD444 RAMs on eBay, but while waiting for them to arrive I thought I'd continue testing...

By the way -- the HP manual has some errors regarding SRAM power on the Controller Board.  My corrections are shown, below, in red:

Excessive Battery Current Drain:

After ordering replacement UPD444 CMOS SRAM from eBay, I decided to look around a bit more and see what other problems I could find while waiting for the SRAM to arrive.

One issue I had noticed when I first opened up the unit was that the battery backup was dead (the battery was sitting at about 0.45 volts), yet it was a fairly new battery (with a 2023 date).  Could it have been killed by excessive current draw?

Note that this battery serves two purposes:

First, it keeps power applied to U203 of the RESET circuitry (CMOS inverters), even when power is OFF, so that the RESET line can be properly driven when power is first applied.

Second, the battery provides power to U211 and U212 (the CMOS SRAM), to maintain the contents in these two SRAM chips even when the unit is powered OFF.

Per section 5.2 of the manual, battery current drain when power was off should be on the order of 1.35 uA (typical) to 18.5 uA (max), when measured as an equivalent voltage drop across R13, a 1K ohm resistor -- e.g. 1.35 uA of current would equal 1.35 mV across R13).

Replacing the dead battery with a bench supply set to 3.0 volts, I measured 0.495 volts across R13 -- in other words, current draw was 495 uA, not the spec'd 18.5 uA max!

No wonder the battery was dead!

The battery-power circuit is fairly simple, which means there weren't many suspects.  And because U212 (one of the two CMOS SRAMS) was on my "hit-list" of suspected bad parts, I decided to clip its VCC pin (pin 18) and see what happened to battery current.  

With the pin clipped (i.e. no VCC applied to U212), the voltage across R13 dropped way down (below the level that my Fluke DVM can measure) -- clearly U212 was the culprit!  

U212 Temporary Replacement Test:

OK -- two different tests pointed to U212 being bad.  Was there some way that I could verify this while waiting for my eBay UPD444 CMOS RAM to arrive?

A friend gave me a National MM2114N-L 1Kx4 bit RAM from his junk box.  This device draws more supply current than the original NEC part, so it would not be a satisfactory permanent replacement for the UPD444, but I thought I would give it a try to test my theory that it was U212 that caused the count-down errors.

So I removed the original part, installed an 18-pin socket in its place, and inserted the '2114 in its place (also, the battery had been removed, too (it was dead) -- if the battery had been good, though, the MM2114N would have presented a much larger than expected current drain, and I would have removed it before doing this test).

I turned power on, and...nothing.  The seven-segment displays remained dark!

Probing with the scope, I quickly discovered that with power ON, Vcc at the '2114 was around 3 volts, not the expected 5 volts.  

Power to the CMOS RAM is a diode-OR'd combination of Vcc (via CR2, when the unit is powered up) or the Battery voltage (via CR3, when the unit is powered down and the CMOS RAM thus battery-powered).

There is a 49.9 ohm resistor (R17) in series with CR2.  The Vcc current of the '2114 RAM was enough to create a significant voltage drop across this 49.9 ohm resistor.

The obvious temporary solution was to short out the resistor for this test, which I did.

Powered the unit back ON, and the count-down was now correct!  Therefore, the count-down problem was caused by a bad U212 CMOS RAM IC.

Here's a video of the correct power-up countdown, with the MM2114N-L as the temporary replacement for U212:

Even thought the count-down is now correct, the unit still fails at the end of the count-down, either by blanking the seven-segment displays (as shown in the video, above) or showing (sometimes briefly) the two error codes mentioned above.

(An interesting question (unanswered) is why did HP add R17 in series with CR2?  My guess is that it has to do with current-limiting CR2's current at power-up, but why?  Note, its P/N is 1902-0535.  With 50 ohms in series and assuming a direct short from CR2's cathode to ground at power-up, CR2's initial current surge would be around 100 mA. Is the Schottky diode that sensitive to a temporary current surge?).

More Troubleshooting continues in Part 2!

Other Manual Issues:

Another Keyboard schematic error:  There are no net names assigned to the inputs of the four U5 drivers ('LS05 devices), so it is impossible to tell which output they actually connect to.

Resources:

HP 3314A Manuals:  https://www.keysight.com/us/en/support/3314A/programmable-function-generator.html

HP 3314A Repair in 3 parts:  https://diysquared.blogspot.com/2021/04/fixing-hp-3314a-function-generator-part.html

HP 3314A Repair on YouTube:  https://www.youtube.com/watch?v=wNxgBubSfH8

HP 3314A Repair (on Antique Radios forum):  https://antiqueradios.com/forums/viewtopic.php?f=8&t=360491

HP 3314A Teardown (EEVblog):  https://www.eevblog.com/forum/testgear/hp-3314a-function-generator-teardown-explanation/

HP 3314A Playing the Hallelujah Chorus:  https://www.youtube.com/watch?v=H90d6sPUF6A
(Note:  Hold down FUNCTION (the blue key), SW/TR INTVL, and START FREQ while powering up the unit).

HP 3314A ROM Images:  http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=01_ROM_Images_and_Drivers/HP_3314A_Eprom

Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.