Fixing an HP 5342A microwave counter. Part 1.

While browsing eBay I came across a HP5342A microwave frequency counter for a very attractive price. Normally, it is a very risky business to buy this instrument, as most of the units on eBay do not work. Usually the input mixer is blown due to overload and that component is unobtainable, unless you have a parts mule with a good mixer. However, in this case the instrument was shown booting with a garbled display and unresponsive keyboard. The seller said that it had been used before. We all know that nothing can be assumed true in eBay item descriptions, but I felt it was still worth trying.

The not working front panel could mean a lot of things, a broken front panel, a broken PSU, a broken CPU but those can all be fixed with a high probability. So I took the chance and won the auction.

Well, the description was correct, It sure did not work. The display has invalid characters and no response from the keyboard.

The display is deterministic, I get the same hieroglyphs on every boot. 

So let's check the usual suspects. I reseated all the cards. Boy, there are a lot of screws to remove to open the internal shielding! The supply voltages and ripple all were within specs. So, the problem is more complex.

Let's start with figuring if it is the front panel or something else. The display has its own memory and oscillator for multiplexing and scanning the keys. The CPU updates the keyboard by strobing the HDSPWRT line which updates the display RAM. The keys generate interrupts and the CPU can read which key was pressed.

Let's look at these signals. Unfortunately all the cards are in a shielded compartment, so it is impossible to access them to probe. The proper way would be to use extender boards. There is a set for the various cards and for the CPU board there is a special one (HP part no.:05342-60036) which is not a simple feed-through board, but has additional switches, logic and test points. Some simple extenders are available on eBay, but they cost more than what I paid for the whole unit. The CPU extender, I have not seen even a reference of anyone having and selling one.

However, not all is lost. Most of the signals are available on the bottom side of the motherboards and also on the back CPU connector, which is supposed to be used in combination with the 5344A unit.
While HP gets some points deducted for the extender boards, kudos to them for extensive silkscreen printing on the motherboard for the various signal names.

So, I looked at the HDSPWRT signal and it was not changing, indicating that probably there is some problem with the CPU unit.

Next step, debugging the CPU unit. I first pulled boards that may affect the CPU, the counter assembly and the Opt 002 card, no change. The service manual actually calls for a signature analyzer, which I do have in the form of a Tektronix/Sony 308 Data Analyzer, but first I need to confirm if the CPU extender is needed for it or not as the manual instructs some switch setting on the riser for the signature analysis. So first let's see what we find without it.

The CPU card has switches to put the CPU into NOP mode, where the data bus is forced to provide the opcode for a one byte instruction. This is usually the NOP (no operation) instruction, but in this case it is the CLR B (clear accumulator B) instruction. Nevertheless, the result is the same the CPU should be cycling trough the whole address range while executing this instruction. One can then put a scope or LA on the address lines and see them counting up, with every higher order bit toggling with half the frequency of the one before.

From A0 to A7 this worked very nice. However, from A8 to A15 I have seen some glitches. With some tweaking on the trigger I was able to capture one of this glitch. Looks like A8 is glitching and that affects all higher order bits of course.

Oops, this looks ugly. Something is definitely wrong.

Test 1. Remove the CPU and with a cut up socket, isolate all signals that are not required for the test and run again. All address lines are now unconnected, so it is not something pulling them high periodically.

Same result. I double checked all pins if I see any correlation to these glitches, but no. Power is rock solid, so are all other pins. I actually removed the CPU card and provided power and 1MHz clock externally. The fi1 and fi2 clock phases are generated in the board from the clock signal, so the whole CPU card can be made running outside the instrument.

So could this be a faulty CPU?

Test 2. Remove the CPU, put it into a proto board, use my Tek AWG2021 to produce the two phase clock.

Wow. There are no glitches. What could make this difference? I have examined the clock closely on the 5342A CPU board, it it in spec, though it has much less separation of the the two phase, but it is still well within spec for the 6800. I see no other difference, except maybe some load on some of the pins. Puzzling.

So this is where I stand now. I'm actually getting a new CPU for a test, just have to wait a couple of days during this virus lock-down times. That should close out or confirm if it is the CPU. Then we'll see where to go forward.

Stay tuned, the result of the CPU replacement will come in Part 2.