Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!daver!bungi.com!news From: george@wombat.bungi.COM (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: my pc532 is almost up. Message-ID: <9008221047.AA15770@wombat.bungi.COM> Date: 22 Aug 90 17:47:45 GMT Sender: news@daver.bungi.com Lines: 265 Approved: news@daver.bungi.com [In the message entitled "Re: my pc532 is almost up." on Aug 22, 8:11, Jon Buller writes:] > > I have the system refreshing its dram now. The solution is to watch what > the supply voltage is... I am running it in the lab through a wire that > appears to have about a 1.5 to 2 ohm resistance to it. Now I keep a DMM > on the power AT THE BOARD and adjust the supply to keep the board at 5V. > Running the board at 4.7 or 5.15 does NOT work... But I knew that, I just > didn't realize that I was doing it. Maybe you should invest in a decent thick power cable to the board. It should still run at 4.7V, and certainly 5.15 (+/-5% right!). So, maybe you are getting transients etc that the VOM wont show. Anyhow here is the debug document, it appears a lot of people never got it off the net last time around: --------------------------------------------- Hi folks, the following is an attempt to generate a debug document for the pc532. As can be imagined it is difficult to cover all possible problems, especially ones that haven't yet occurred. Expect (I hope not) that this document will grow as we get more feedback (problems?). Thanks to John C. for some of the material. In outline form: Materials needed: ----------------- 1). Assembled pc532 without IC's installed and without BCLK terminators installed. 2). IC's. 3). PC power supply. 4). Terminal / terminal emulator. 5). Terminal cable(s) (eg. 10 pin header -> 10 D-sub -> 10 to 25 pin adapter -> 25 pin cable) Optional/essential materials: ----------------------------- 1). RS-232 break-out box. (To facilate swapping connections and to provide visual indicator of line state). 2). Logic probe. If you are running at 25MHz, then the logic probe better be able to resolve 20ns wide pulses of better. 3). Multimeter. 4). Oscilloscope (the higher the bandwidth the better, 100MHz is more than adequate for checkout). Even a 35MHz scope is better than none. 5). Logic Analyser? Support equipment checkout: --------------------------- 1). Verify RS232 cabling results in desired connections. 2). Verify terminal / terminal emulator is functioning. 3). Verify power supply voltages. 4). Verify power supply connector cabling. Note: Many PC/XT/AT powersupplies (switching supplies) will not operate correctly without a load. In fact many will not operate without a reasonable load on the +12V supply. I usually use an old floppy/hard-disk as a load. Prime equipment (ie pc532) checkout: ------------------------------------ 1). Solder in all resistors/capacitors/sockets/connectors. Take extreme care in orienting the PGA and PLCC sockets correctly. The correct orientation is silkscreened on the top of the PCB. If you solder the PLCC sockets in incorrectly, you are in real trouble! 1a). After soldering in all resistors/capacitors/connectors etc, but before inserting any integrated circuits, measure the resistance from +5 to ground. You should not have a short circuit (!), the resistance should be roughly 11 ohms (due to the terminator resistors, 4 packs x 12 effective 550 ohm resistors in parallel across the +5/Gnd. Verify that there are no shorts between +/-12 and +5/Gnd. 1b). Sanity check, without chips, apply power and check voltages. Make sure the two power connectors are not interchanged before applying power (eg. black wires on each connector are adjacent, this means that the black wires (all of them) are in the middle of the connector). 2). Insert all chips, except for the parity PAL U20. 3). Inspect all chips to make sure the pins are properly seated. Make sure the PGA devices are fully seated. Double check that the ring on certain PGA pins is level with the surface of the socket. (This one bit me. I did not have the 32532 fully seated and as a result one or more of the 175 pins were intermittent). 4). Insert SIMM's. Closely inspect the seating of each device. Make sure the SIMM's are at 90 degrees to the motherboard and the contact fingers are fully engaged in the socket. If you have 8 Mbytes of RAM, my recommendation is to start with 4 Mbytes. The theory being that it is easier to inspect for proper seating and there are 4 fewer items to cause trouble. With 4 Mbytes, connector positions U6, U8, U10, and U12 should be occupied. 5). Configure jumpers. With 4 Mbytes (ie: 4 SIMM's of 1M x 9) J1 - jumper between pin 2 and pin 3 J2 - jumper between pin 2 and pin 3 J3 - open (shorting resets the hardware) 6). Smoke test, apply power, re-measure power supply voltages. 7). The LED's should glow. If not, the ROM code did not execute. 8). Connect terminal and verify ROM Monitor operation. The terminal connects to CONN3, and the terminal should be configured for 9600-N-8. 9). Install parity PAL (if you have x9 DRAM SIMMS) and re-verify operation. 10). If you have 8 Mbytes of RAM, install remaining SIMM's. 10a). Re-verify operation. 11). Install BCLK terminators. 12). Re-verify operation. Misc thoughts, in case of trouble: ---------------------------------- 1) Lower the CPU clock frequency (eg 25Mhz module) by changing out the osillator in U25. This should eliminate any possible time delay problems (eg, using lower speed parts) and make it easier to scope for vital signs. 2) Verify vital signs with a scope. --------------- Following are some discussions over a dead pc532: Still trying to debug this thing. In answer to your first query, there's no chip select signal going to the ICU (and thus no refresh signal either). The supplied monitor will program the ICU to generate a 30usec square wave on the counter output of the ICU. This operation is performed in the first few instruction of the monitor (before any DRAM/DUART/SCSI operations). If this step fails then something very drastic is wrong (and basic). I checked all 8 data lines coming from the EPROM and there does appear to be data coming from them. Same with the data pins of the 32532 and the output from the 646 (if there's data on the CPU pins I assume that it's coming back..) Anyway, I noticed something that may or may not be important and I figured I'd ask about it.. We were examining the clock outputs and noticed that we were getting BCLK from the CPU but not /BCLK. I'm not sure of C23 is bad and is dragging it down or if it's just not coming from the CPU at all. Is this normal? BCLK and /BCLK come from the CPU, they are always present, even during reset. There must be a short circuit somewhere, find it. /BCLK is used (among other places) to clock /DDIN through U26 to form /DDINL. /DDINL is used (among other places) to control the direction of U43 (the 74AS646) which buffers all data to and from all 8 bit devices (including the EPROM). If /DDINL is stuck high, because /BCLK is missing, then U43 will always drive data to the peripherals even if a read is in progress, and visa-versa. Like I said, the EPROM does appear to be getting addresses and does appear to be getting data (if lots of indecipherable staircase signals == ADDRESS/DATA signals, that is) back to the CPU. That's all I've managed to figure out so far (help from the hardware hackers has not yet materialized). On a similar note, the clock signal from the 20MHz crystal appears to be 1/2 the amplitude of the 50Mhz clock. Also normal? I noticed this while checking the termination resistors and seeing that I had soldered one of the 220 Ohm guys to pin 6 (+V) of the 74F138 which was only +2VDC. I said "Hmmmm. Wrong. +V is a pullup in RES13. You must connect to +5V directly. The spec does say 2VDC min for that guy, maybe I'd better solder this guy to somebody who explicitly claims to be 5VDC instead of this pin. I then re-soldered it to the VCC of the 74AS1034 and got thereafter 5VDC on pin 6 of the 74F138 as well! The 20Mhz clock signal stayed at its previous amplitude. The 20MHz clock should reach at least the minimum high for TTL, i.e. it must get to at least 2.4V, I would suspect that the module is faulty, since the only load is the AIC6250. ------ Hi, well let me just mention the initial things you should check for, we'll get more complicated as necessary: The software in the EPROM attempts to 1) program the ICU for the refresh, you should see 30usec (approx) square wave coming from Pin 29 of the ICU (U46). 2) Jump to the high EPROM address from the 0 address and then program the ICU to assert the SWAP signal low (should be high at reset). SWAP comes from pin 11 of U46. 3) Program the AIC6250 SCSI chip to assert all the LEDs (i.e. all LED outputs go low, lighting the LEDs). All 8 LED signals should go low, for the 4 LEDs on the board + the 4 on CONN2. 4) The DUART gets programmed etc etc. So, the first thing to check is whether the ICU gets selected after reset, i.e. pin 21 of U46 should blip low. If this happens then you should see the 30usec square wave. If you have got this far then the EPROM must be basically working (email me if you get this far). If the ICU never gets blipped then you have a real basic problem with the data getting to the CPU. The things to check are that all the data lines from the EPROM get to the 74AS646 and from there to the CPU. Make sure that the 74AS646 is actually functional. Also check that the DEC32 pal is outputting the right signals. You should see /EPROM being asserted and also /SLOW and /SLOWS which controls the gating of data via the 74AS646. To check the gating controls of data from 74AS646, the /DDINL signal from U26 should be mostly low (for read), but it should blip high (especially after each reset, since the 32532 writes to the ICU, then the SCSI and then the DUART) and /PERG from U58/B should be low to gate the data on via U43. /PERG is also used to inform the 32532 that the current address refers to an 8 bit device (via the BW0,BW1 inputs of the 32532). /PERG should always be low for any peripheral select, the DRAM being the only 32 bit device. Also if /EPROM and /RD are both asserted but the /NRDY (pin 13 U38) is stuck low (after reset) then the WAIT pal is doing something screwy. /NRDY is the not ready for peripherals and /NRDYR is the not ready for the DRAM. They get or-ed/inverted by U30/A to form the /RDY for the 32532, i.e. when /RDY is low the 32532 can finish the bus cycle and go on to the next one. I have high confidence with the PALS since I ran test vectors through all of them (took a long time!!!). Similarly with the EPROM. Also make sure that RES13 (the 4.7kohm pull up dip) is plugged in the right way, and that BCLK and /BCLK are both toggling (they are the clocks coming from the CPU that go to the rest of the system). Basically all that needs to work to get the ICU to generate the square wave is: U35, U30/A, U25, U44, U46, U37, U38, U42/A/B, U43, U58/B, U39, U45 and U50. The /A etc is the gate number. U45 buffers the low address lines from the 32532 to drive all the peripheral address selects (for the internal registers within the peripherals). Anyhow, try that and we'll see if we can track the problem down a step at the time. --------------------------------------------------------- -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]