HP 3478A microprocessor being reset regularly

[torquil]

Hi!

I wonder it anyone here could offer some help in repairing a HP 3478A, bought on EBay as "parts only".

When powering on, some illegible black symbols appear momentarily along the top of the display.
Otherwise, the display is blank. The 3V RAM backup battery was completely drained out, so I will
have to do some kind of calibration once I get it up and running. I have removed the battery completely
for now. All the jumpers are in the right position. The power rails seem fine. But what is the maximum
acceptable ripple on the 5V rail at the Vcc pin, that will still not disturb the processor?

The problem now is that when probing the RESET-pin (pin 4) on the U501 microcontroller (which
apparently is an 8039 microcontroller), I see that the processor is reset around every 1.3s. This
time period fits with the description of the counter chip U507 in the service manual, which will
cause a processor reset around every 1.3s if not stopped by the keyboard button scanning that
the processor is supposed to perform.

In the 7-F-59-b section on the reset circuitry, it is described that the processor emits a signal
on pin 31 to the keyboard as part of the keyboard scanning, and this will cause the counter chip U507 to
not reset the processor. However, my 3478A does not emit this signal on pin 31, so the processor is
reset every 1.3s by the counter U507.

The power rails look fine to me. The connections from the D0 through D7 (pins 12 through 19) on
U501, to the RAM/ROM chips are fine. The Xtal oscillator on pins 2/3 on U501 is also fine. The
ALE oscillation on pin 11 on U501 is also fine.

I've looked at service group D in the service manual which is for power-on troubleshooting, but
it tells me to use a "signature analyzer", which I don't have. Is there a way to do the "signature
analysis" manually using a 4 channel oscilloscope, or several oscilloscopes?

Could it be that the ROM data is bad, so that the processor is never able to start running through
the program that it should be running, and therefore is not emitting anything on pin 31, and is
therefore reset every 1.3s due to the reset circuitry?

There is one more thing: When scoping the signal on the "data bus" between the processor and the ROM,
the waveforms do not look particularly nice. I'm aware of the possibility of "bad probing". I tried
to avoid that By using the "spring-attached" grounding pin near the tip of the probe, and probed
pin 17 of U501 while touching the ground pin 20 at the same time. See below for waveforms. The
oscilloscope has 200 MHz bandwidth, but with a 100 MHz probe.

And BTW, forcing the RESET pin 4 on U501 to be high does not help :-)

ALE signal on U501 pin 11:


Crystal oscillation on U501 pins 2/3:


Reset happening every 1.3s, as seen by probing on U501 pin 4:


Some scope screenshots of activity on data bus pin 17, using the nearby pin 20 as ground reference:

[m k]

The signal of pin 31 must be programmed and since 8039 has no ROM there can be some basic access problems.

You can start from TP4 and RP527, quite an interesting part BTW.

[torquil]

I found a 8039 microprocessor datasheet from Intel that shows how the signals on the bus (e.g. pin 12 on U501) are related to the ALE (pin 11 and test point 3) and PSEN (pin 9 and test point 4) signals during reading from the program memory. This shows that the signals are floating part of the time, and it seems to me that this fact can explain the waveforms I'm seeing on the scope. At the time intervals relative to the ALE and PSEN where the bus signal is not floating, it looks OK to me. It is always either high or low there. So I'm now leaning toward the program memory in the ROM chip being corrupt, instead of a malfunctioning microprocessor. Is that a likely scenario?

[m k]

Those shapes from lower pictures should be much more rectangular, like the first one.

ROM is a good candidate but since everything is connected it's hard to say.
It seems that you need a multimeter for more accurate measurements.

Basically,
first ALE separates data and address to the latch(U513).
Then address stays there and ALE is released.
Then ROM OE(TP4) is activated and its data read.
So anything that is connected to U501 D0-7 can be it.

[torquil]

Those shapes from lower pictures should be much more rectangular, like the first one.

Ok. But I wish I could find some oscilloscope measurement examples on a similar microcontroller on the same pins. I checked that the pullup resistors in R513 was OK and that the 5V rail to which they are connected is stable, and that seemed OK. The 5V rail is also OK on U501 and all the surrounding active components.

RP527 is OK and the connections between D0-D7 to e.g. ROM and RAM is OK. The nearby capacitors are OK. I will look for a block diagram of the U501 internals to see if it is likely that there can be an internal fault that will cause the signal on all the pins D0-D7 to have such "distorted" waveforms, but I hope I'm not barking up the wrong tree. That's why it would be nice to see actual waveforms on D0-D7 on a working 3478A or something else using the same microcontroller.

If the ROM data is corrupt I guess it would only cause wrong data, not distortions on the communication signals between it and U501. I will also try to verify that U513 is working properly.

[m k]

Yes, corrupted data is corrupted data, it doesn't affect the general operation of the chip.
Same with shorted pin, it is really shorted and line is then stuck.

For the distortion,
if not usual it's for sure much more than hardly seen.

It's also possible that there are more than one chip enable active.
Only one of _PSEN, _RD and _WR should be low at any time.

What chips you can remove?
If you can take U501 out you can then pulse TP4 down and check what happens, leaving TP4 down for longer time is also fine.
For some other address just pull few datalines down and tap ALE down, floating value should be up.
Without U501 tapping ALE will also disable RAM, HPIB and U510 by putting U506 outputs up.

[torquil]

It's also possible that there are more than one chip enable active.
Only one of _PSEN, _RD and _WR should be low at any time.

Only PSEN is doing any alternating between LOW and HIGH. RD and WR is only HIGH (they are a bit noisy, but quite close to 5V, so HIGH).

[m k]

Time for decision then, are you cutting the ROM out or not.

If you don't have an easy way then you should cut legs off from body side.
Then you have two possibilities, new legs over or under those old ones.
If over then you should cut old legs so that they are straight and go nicely between new chip body and legs and don't lose those tiny old leg bits somewhere making shortcuts.

[torquil]

I think I will be able to the ROM out OK with my desoldering equipment. My problem now is to get a compatible ROM replacement and associated programming equipment, which I don't have. I found a thread with some interesting info regarding a very similar problem on a related DMM, the 3468A: https://www.eevblog.com/forum/testgear/hp-3468a-in-continual-resetinit/

[m k]

Your ROM seems to be 2764, you can also use EEPROMs and flash ROMs.
Standard is standard.

But if you can suck one ROM pinhole empty you can also easily disconnect it.
Then when ROM pin is disconnected you can verify how things behave.

[torquil]

It turns out I have an older 3478A which uses a 24-pin ROM. The service manual discusses the change from 24-pin to 28-pin ROM. Without knowing anything about ROMs, I believe the one I have corresponds to a 2364 type ROM. At least the pinout seems to be the same as what I found on a 2364 datasheet.

Thanks for the tip, I will disconnect power to the ROM and see e.g. if the processor gives a ROM error message on the display instead of the endless resets with a blank display.

[m k]

24 pin is the old one but no problem, just get an adapter.

BTW, just found out what signature analyzer means.

Have you reseated that data bus breaker RP527?
If male part pins are not clean you can lift it a bit so that the connection is in different position.
You can also check how signals behave when it is off.

ROM error message is far ahead of your situation.
I read that folks are getting that and still use the meter without any problems.
It's possible that that is a partial ROM CRC error of some sort.

If you check how that signature analyzer thing goes you see that JM503 placing is different.
That's grounding A12 and can be an activation of test section of the ROM.
But there is also TP7 and 8, those are normal operation pins and are indicating that the ROM section is not exclusively for testing.

So you most likely can't use 2732 connection and it's not pin compatible anyway.
But with adapter you can use bigger chips and few switches, in case you are not sure what version your ROM was.
27512 is 8x so 3 switches is needed, maybe 27256 is better, but if you go to SMD direction those are pretty irrelevant, there probably is a ROM emulator MCU board with micro USB.

[torquil]

So I ordered a TL866ii Plus programmer, some 2764 EPROMs and a 2364-2764 ROM adapter. I programmed the 2764 with the HP3478A ROM dump from KO4BB. Now the unit works! So the ROM was the culprit.

Now it remains to get a replacement Lithium battery and to calibrate it, becuse the Lithium battery was dead when I received the unit.

[ChrisG]

Hello all, does anyone know if the RS PRO Lithium battery rated at 3.6V nl.rs-online.com/web/p/speciality-size-batteries/1835723/ would be suitable as well. It should drop in physically and I guess the 0.6V extra would not be an issue. Any comments?

[pqass]

Hello all, does anyone know if the RS PRO Lithium battery rated at 3.6V nl.rs-online.com/web/p/speciality-size-batteries/1835723/ would be suitable as well. It should drop in physically and I guess the 0.6V extra would not be an issue. Any comments?

The RS PRO looks fine. 
I'm using this one: https://www.eemb.com/model/er17335.html
Really, any battery that is greater than 3V but less than 4V would be fine.
My original battery was as low as 3.0V before I replaced it.

If you're interested in my procedure to change the battery and other 3478a info, follow the links in this message:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3407018/#msg3407018

[ChrisG]

Thank you... perhaps I'll switch back to the Panasonic although it seems that shipping tends to be an issue (airshipment) so need to find a good local Dutch supplier. For the RIFA caps I'm moving to PP's from Kemet or WIMA I would imagine that this is better then the paper, metal ones from e.g. Kemet.

[pqass]

Thank you... perhaps I'll switch back to the Panasonic although it seems that shipping tends to be an issue (airshipment) so need to find a good local Dutch supplier. For the RIFA caps I'm moving to PP's from Kemet or WIMA I would imagine that this is better then the paper, metal ones from e.g. Kemet.

As for the battery, I didn't want to wait and mail-order a "better" brand (like Panasonic).  The EM3 brand was readily available locally.   Since I've successfully read the calibration data, I wasn't worried about it.

As for the caps, I went for PP Y2 caps that were on sale.   

[m k]

Alternative Cal-RAM reader.

Just replace the jumper block with a mini MCU board, CPU side is program code and other side is RAM data.
Few needed extra signals have TPs and finding GND shouldn't be a problem eighter.

So it needs 7 inputs(4 data, 3 control), 8 outputs and GND.

Code: [Select]

  TP  block
 ALE   B8h  mov R0,#00 8039 BUS is floating
                       MCU is ready to put out B8h
_PSEN                  ROM read
                       B8h to CPU side of the jumper block
 ALE   00              same continues
_PSEN                  release BUS when ALE is down and _PSEN is up
       next:
 ALE   E4h  jmp 700h   P23-20 must be kept 0111
_PSEN
 ALE   00
_PSEN
 ALE   80h  movx A,@R0
_PSEN                  leave 8039 BUS floating when _PSEN rises
 ALE                   8039 is addressing the RAM
_RD    Fxh             read RAM data from other side of the jumper block
 ALE   18h  inc R0     back to
_PSEN                  ROM read
       loop next       exit after 256 rounds or check it doing multiple passes
       end

Write single nibble

Code: [Select]

  TP  block
 ALE   E4h  jmp 700h
_PSEN
 ALE   00
_PSEN
 ALE   23h  mov A,#nn
_PSEN
 ALE   nn               data
_PSEN
 ALE   B8h  mov R0,#nn
_PSEN
 ALE   nn               address
_PSEN
 ALE   90h  movx @R0,A
_PSEN
 ALE
_WR                     don't forget the CAL switch