Debugging the HP37201 HPIB Extender
Tony Duell
ard at p850ug1.demon.co.uk
Thu Sep 8 17:43:04 CDT 2005
I think this is on-topic here, it is well over 10 years old, it contains
a classic-type microprocesosr, and I suppose it could be classed as a
peripheral for a computer system (it's more commonly used to do
remote-control of test equipment, but...)
Note that I have a circuit diagram for this unit, but no service manual,
so I couldn't interpret the self-test LED patterns. But I sorted it out
by thinking about what had to be going on...
To cut to the end, would you believe _another_ dead 2114 RAM chip....
-tony
> The HP37201 is a unit that allows an HPIB (GPIB, IEEE-488) bus to be sent
> over a serial connection. It supports various forms of the latter,
> including asynchronous and synchronous modems and twisted-pair cable.
>
> Physically, it's a 2U rackmount unit. To get inside, remove the top and
> bottom panels with the captive screws at the back. The right side panel
> can then be removed in much the same way. To get the left side panel off,
> remove the 2 screws at the ends of the handle, the plastic covers under
> them, and the handle itself. The panel then slides off towards the back
> of the instrument.
>
> Inside there is one large PCB filling most of the case. It contains a
> 6800 processor, 8K of frimware EPROMs (either 8 off 2708, 4 off 2716 or 2
> off 2732, sleected by soldered links on the board, mine has the middle
> configuration), 1K of RAM in 2 off 2114, a 6850 async serial chip, a 6852
> sync serial chip 5 off 6821 PIAs (1 for the diagnostic connector and
> front panel LEDs, one for the GPIB data lines, one for the GPIB
> handshake/control lines, one for the internal configuration switches and
> GPIB control, and one for serial control and handshake lines), GPIB
> buffers, RS232 buffers, and a bit of TTL. The latter is mostly for the
> encoder/decoder for the twisted pair connector, but of course there's a
> little for the GPIB port, system address decoders, microprocessor address
> buffers, etc.
>
> The PSU is on the same board, but HP have been kind to people like me who
> like to test it on dummy (or no) load first. There is a 12 pin (6 pin
> double-sided) edge connector on the PCB. Some of the pins go to the PSU
> outputs, others carry the power lines to the rest of the machine. In
> normal operation, a little jumper PCB (no components, or even soldered
> connections) is plugged in there. It can be removed to test the PSU
> without the rest of the machine conencted. Incidentally, the marked PSU
> testpoints are on the PSU side of this connector, and are thus useful
> when the jumper is removed.
>
> The only other things in the case are the mains transfomer and associated
> input connector and power switch, and a 'DTR OFF' changeover switch that
> connects the DTR pin on the RS232 connector either to the DTR buffer
> output or to another buffer output that is permanently at -12V.
>
> There are 2 DIP switches and a rotary switch on the PCB. The latter
> selects the transmission mode/baud rate and self-tests.
>
> OK, so what did mine do. Well, in the process of fully dismantling and
> reassembling it (not to be recomended if you don't like fiddling tiny
> nuts into even smaller spaces -- the connectors are all soldered to the
> mainboard and have to be unbolted from the back panel to get the board
> out), I'd removed the 3 fuses from the PSU section of the PCB. There's a
> 3A fusr for the +5V line, a 0.5A fuse for the +12V line, and another 0.5A
> fuse for both the -12V and -5V lines. I put them back in suitable places
> and powered up with the jumper pulled.
>
> The +5V and -ve lines were fine, the +12V line was missing. I quickly
> traced this to a blown fuse. Since I'd not seen it blow when I flipped
> the power switch, I replaced it, the +12V line now came up correctly.
>
> I fitted the jumper and powered up again. The -ve supply fuse flashed and
> failed. I suspect.actually, the fuse I had put in the +12V holder had
> originally come from the -ve one, it had failed long before I started
> fiddling with things. A bit of checking showed that there was a short
> from the -5V line to ground, and that a 75110 buffer (line driver for the
> twisted pair cable) was getting rather hot. I desoldered it, replaced the
> fuse, and tried again. This time the fuse held, and the instrument should
> work for other-than-TP links without this buffer.
>
> Alas it didn't seem to be working. None of the LEDs came on other than
> the power light (which simply runs from the 5V line). Fiddling with the
> CTS and DSR lines had no effect on the associated LEDs (note : The 'link'
> is in software, the RS232 lines are read via pins on one PIA, the LEds
> are driven by another). More worrying still, at least one of the PIAs was
> not being initialised, a pin that drives a select input on a mux to set
> the async baud rate [1] was left configued as an input.
>
> [1] The async baud rates are quite clever. The unit can officially do
> 150, 300, 600, 1200 baud. The 6850 can do either /16 or /64 between the
> clock input and the internal bit clock, so one clock input frequency will
> do for 300 and 1200, half of it would do for 150 and 600. There's a mux
> that selects the appropriate output of a counter depending on the state
> of a PIA pin. There's also a soldered link that would appear to double
> all the baud rates, I've not tried it yet.
>
> I twiddled the rotary switch and powered up again. Now the first
> interesting thing was that in 2 of the self-test positions I did get some
> front panel LEDs on. So the CPU was clearly running. It could do enough
> to intialise the PIAs, read the configuration switches, and drive the
> LEDs. I'd already pulled the socketed EPROMs and dumped their contents. I
> couldn't be sure it was correct, obviously, but they looked sane.
>
> One of the test positions was clearly a memory test (I forget the
> labelling). Now, for very good reasons, namely that they were 2114s, I
> suspected the RAMs. Getting to them is not easy, they're at the very
> front of the board, partly hidden by the front casting. So I had to get
> that out of the way first.
>
> Disconnect the DTR OFF wires at the back of the PCB (note the order, they
> are not marked on the PCB). Pull the cable through the grommet, undo the
> 2 screws and nyloc nuts holding the cable clips to the right side
> casting. Prise off the trim strip at the top of the front casting, remove
> the 6 screws holding the front panel. Pull that forwards, remove the 2
> screws holding the mains swtich to the back of it, then remove the front
> panel. Don't worry about the lack of the DTR OFF switch, you don't need
> the DTR pin to sort out the memory.
>
> With the front panel out of the way, the front casting comes off with the
> 4 corner screws..
>
> OK, I desoldered the RAM, and fitted 18 pin DIL sockets. With no RAM
> chips at all, I got a different set of LEDs on the memory test
> (interesting, at least it was doing somethign with the RAM). Putting the
> RAMs back gave the old pattern, putting them back the other way round
> (swapping which chip stored each nybble) gave a different pattern.
>
> Had the RAM been working correctly, swapping them would have made no
> difference of course. So it was likely I had a RAM fault.
>
> I found an old Apple 80 column card with some socketed 2114's on it.
> Pulled a couple and put them into the 37201. Powered up. Got yet another
> patten from the memory trst. The self-test now gave a patten of flashing
> LEDs (test-complete alternating with all the others). The 'operating'
> modes now gave a single LED on, which indicated 'remote signal lost' --
> not suprising as I had nothing connected to it. More usefully, the RS232
> handshake pins now did affect the frontpanel LEDs, the baud-select pin
> from the PIA was now driven correctly.
>
> Trying the origianl RAMs back one at a time proved that only one was
> dead.
>
> Still to do : Get a new 75110 driver chip for the TP interface. And
> investigate the lowest hardware test, which doesn't even use the firmware
> ROMs, with a logic analyser
More information about the cctalk
mailing list