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