news@daver.bungi.com (08/21/90)
Could some of you out there give me some hints as to what I am doing wrong when I try to bring up my board? I can not see any activity on the ras, cas, or other dram signals, but there are some pulses on bank0. Also there are 200nS pulses about .5uS apart on slow, eprom, and the like. Is this normal? (I would expect some dram activity for stack...) I also do not see any activity on duart0 (or the others either.), and I have a PC com port hooked up to con3 on the board. I do not see any activity on the PC, at any speed I have set it for, what speed should I set the PC for, and what should characters should I send down the wire to wake the board up? Thanks for your help, and maybe VERY SOON (I can feel it...) I will have a working board. ---------------------------------------------------------------------- Jon Buller ..!texsun!letni!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
george@wombat.bungi.COM (George Scolaro) (08/21/90)
[In the message entitled "my pc532 is almost up." on Aug 20, 15:26, Jon Buller writes:] > > Could some of you out there give me some hints as to what I am doing > wrong when I try to bring up my board? I can not see any activity on > the ras, cas, or other dram signals, but there are some pulses on bank0. At the very least refresh should be happening (if the monitor is coming up at all). The pc532 uses CAS before RAS refresh, and hits both banks at the same time. So, if not RAS and CAS, check the refresh clock coming from the ICU (RFRQ, software programmed to give a 30usec square wave) if none then back track some more. If you have refresh out of the ICU, check it after it has been synchronised at the input of the DRAM pal, if it isn't there then the synchroniser is dead. If it doesn't come out of the ICU then the monitor is not coming up at all, which means there is a problem getting data out of the EPROM to the 532. Also check that reset is there, ie make sure that it is available at RSTo and /RSTOUS from U42 (the schmitt) and from /RSTO from U50 (the synchroniser). > Also there are 200nS pulses about .5uS apart on slow, eprom, and the like. > Is this normal? (I would expect some dram activity for stack...) I also > do not see any activity on duart0 (or the others either.), and I have a > PC com port hooked up to con3 on the board. I do not see any activity on CON3 is the correct port for the monitor to sign on, but if you don't have RAS/CAS refresh then it's unlikely for the monitor to be running. > board up? Thanks for your help, and maybe VERY SOON (I can feel it...) > I will have a working board. Hope so, keep us advised of your progress. Do you have a copy of the debug document that John Connin and I put together. Does everyone else have a copy (electronic, it didn't exist when the kits went out)? Does anyone else need it? Best regards, -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]
jonb@vector.dallas.tx.us (Jon Buller) (08/22/90)
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. I have seen the correct voltages across the leds, but never have seen them lit up. I thought I had them in backwards, and pulled them out, but I am told (by people who know which lead in the epoxy) I had it in right, so I suspect that I had some bad leds, but I don't know how they could have gotten burned out. > CON3 is the correct port for the monitor to sign on, but if you don't have > RAS/CAS refresh then it's unlikely for the monitor to be running. Well, I still haven't seen any activity on the port, /duart0, or anything else, but it would be hard to catch on a 'scope (even if I do have it...) Bruce, could you write me a short program to replace the monitor with a program to continuously spew characters out all the serial ports? That would make it much easier to see if the signals are getting to the duarts. I am using some Dallas Semiconductor NVRAM instead of an EPROM, so it is very easy for me to change it, but I don't have a working compiler or assembler at the moment... 8-( > Hope so, keep us advised of your progress. Do you have a copy of the debug > document that John Connin and I put together. Does everyone else have a > copy (electronic, it didn't exist when the kits went out)? Does anyone else > need it? I could use a document like this... can you send me a copy, or maybe post it if others need it too. ---------------------------------------------------------------------- Jon Buller jonb@vector.dallas.tx.us ..!texsun!letni!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
george@wombat.bungi.COM (George Scolaro) (08/23/90)
[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]
news@daver.bungi.com (08/23/90)
Well, things appear no closer than a couple of days ago. I moved my DRAM to sockets 6, 8, 10, & 12 instead of 6, 7, 8, & 9 where I had them. I also moved the shorting blocks from 1-2 to 2-3 since I have 1MB DRAM SIMMs. The BIG thing I saw was that ICU pin 29 (COUT/SC or RFRQ) was a 1.8MHz square wave NOT 30uS. LEDs are still on (actually there aren't any LEDs on the board, but there is voltage across the pads.) Also, now I am getting some noise on the serial port. It is not a sign on message, and may only be some garbage, but I wasn't ever getting junk on the line before. I think this all implies that 1) the 32532, EPROM, and 6250 all work. 2) The ICU doesn't, or there is bad code in the EPROM, or there is something else bad in this line. 3) The DUARTS MAY (or may not) work. I am still open to any suggestions, hints, or clues that any of you may be able to provide. Thanks, ---------------------------------------------------------------------- Jon Buller ..!texsun!letni!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
news@daver.bungi.com (08/25/90)
Well, maybe it's not so close to being up after all. The LEDs start out with both pads at +5V and shortly after reset the pads nearer to the 6250 drop to GND. So, I am pretty sure that the LEDs and 6250 are fine. However, the ICU is not looking so good. I wish I could send you an email polaroid of the scope display, but I'll do my best with a 80x24 display... ---- - ---- - | | | ________________ ------| | | |_| |__/ |_| This is what the data lines from the 646 and into the ICU look like. The bottom line is 0V the next one up is 2V the near top one is about 4.5V and the top is 5V. All 8 data lines look like this. The 646 input data lines look much better, but have gliches on them and have several short pulses that are only about 1V tall... (like this [I hope]) -------------------- -------------------- | | | | | _ _ _ | |__| | | |__| those small pulses at the bottom are roughly square and about 1V tall, but other than that I think it is reasonable. And, just to make sure you don't interpret the / wrong in the first signal, it does ramp up to about 2V, kinda like there is a cap on it and some resistors to pull it to 2V and then the data line gets tri-stated. But the edges from 2V to 4V and 4V to 5V are very sharp. I believe that both signals as drawn are about 20uS from start to finish, and they are regular. (I am not beside the scope right now, and I don't remember the setting, but I believe it was 2uS/div with about 10div across the display...) Is this the way it should look??? I am not really used to seeing digital signals that run to 2V and 4V, but then I can imagine that I could make it happen without too much trouble if I wanted to. Any ideas? I am always open to suggestions, esp. now! -- Jon Buller jonb@vector.lonestar.org ..!texsun!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
news@daver.bungi.com (08/25/90)
One quick thing that I forgot in my other post: swap never goes low after reset. I s'pose that this really shouldn't be a suprise, since the refresh counter is not being set right, but who knows, maybe that little fact will set someone to thinking about the correct solution to my problem. -- Jon Buller jonb@vector.lonestar.org ..!texsun!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;