Fixing an HP 5342A microwave counter. Part 2.

Continuing from Part 1.
I got a new CPU, this time in a plastic package, not a shiny ceramic with golden cap, but should be good otherwise. The questions are: a) was the original CPU faulty and b) did a new one fix the instrument?

And the answers are Yes and No.

I installed the replacement CPU and tested. Exactly the same result, the instrument is frozen with garbled front panel. However, I don't have the glitches on the address lines. While apparently this did not affect anything, it still indicates that something is at least marginal with the old CPU.

How to proceed? At one time HP was very keen on signature analysis, which can indeed help in some cases at least by confirming that the tested part of the circuit works.

I am now beginning to suspect that one of the ROMs may be bad, which would suck, but first I must make sure that I can test is properly.

Why do I think that it may be ROM problem and not, for example front panel? Using the test switches on the CPU board, I can disable individual bits of the data bus. Obviously the CPU would be running a nonsense random program in this case, but for example disabling bit 3 will make it run in some loop, where the front panel display are changing. Obviously, the strobe signal to write into the panel is activated randomly and whatever random data is there will get written into the display.

At least this is what I think, it is still possible that the front panel is faulty and I'm chasing a red herring on the CPU board. But first I want to confirm whether the CPU board is good or not.

For this there are extensive signature tests in the service manual. First in free run (NOP) mode, which tests all the address lines and all the various device select signals which actually covers a large part of the login on the board. This can indeed be done by powering up the CPU board outside the instrument.

So, let dig out the trusty old Sony/Tektronix 308 Data Analyzer, which can do signature analysis and some rudimentary serial and parallel logic analysis and looks like a cute little oscilloscope. And for some insane reason it is usually cheaper on eBay than a HP signature analyzer which can only do signature analysis.

Well, all signatures check out OK. So at least these parts are good.

The next step would be to do a signature test on the ROMs. And that is where I stop now, as it does require the CPU extender card which contains additional logic to provide the start and stop signals for the ROM signature test. I don't have this card, but a kind gentleman on the Vintage HP equipment group pointed out that the schematics for the extender is in fact in the service manual.

It is not complicated, so I'm now tempted to put together one on a breadboard and be able to do the analysis as I really want to confirm if the ROMs work or not.
So I'll continue in Part 3.

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.