gs@vw25.chips.com (George Scolaro) (11/07/90)
Ok Jon, I'm convinced! Your stupid Convex system doesn't know your bach system. Find and destroy your system administrator and all paths forward and backwards from his/her family tree. Since, others (barely) may find some of this useful if they have to debug their pc532, I'll send it out on the general mailing. Please try and get your system working so I can email direct. I gave up after 3 attempts. Hi Jon, well lets see if we can track this problem down. > 1) BLCK at C24 and /BCLK at C23 are 40ns square waves with slightly > ripply high and low portions. As displayed on my scope, both > BCLK and /BCLK began with a rising edge off the "center line." > (If they were truely inverse signals, wouldn't one of them start > with a falling edge? Or is this merely an effect of the scope's > timing and display characteristics?) They must be the inverse of each other. The only way to look at them is with 2 channels of the scope at the same time. With the scope on chop mode, the BCLK and /BCLK must appear as mirror images. If not the CPU is dead! > 2) SWAP on pin 11 of ICU is high, goes low during reset, immediately > returns and stays high. This is broken. SWAP high -EPROM at 0, software then programs it LOW to move DRAM to 0. The EPROM then appears in high memory only (rather than two places as it does with SWAP high) and the code continues to run (it is assumed the code jumper to the high EPROM address prior to setting SWAP low!!). We need to discover why SWAP gets set high, the PC532 will definitely crash if this happens. Do the LEDs on the AIC6250 scsi light up? That is the first thing that gets done after the code jumps to high EPROM and after SWAP gets set low. > 3) /ICU coming into ICU pin 21 "triggers" low. I dont' actually see > the trace go low, but my scope's trigger light says blip. > 8) I get a 30 usec square wave on ICU pin 29. It would appear that the code is running fine at the start since the 30usec square wave is the refresh clock. So, the EPROM code isn't 100% dead. > 5) /DDINL @ pin 2 of U26 is basically high, but blips low frequently > during reset. Since /DDINL toggles low for every read access, it leads us to believe that it CPU dies some time after reset. > 6) /RD coming into ICU pin 30 is high, blips low several times on reset. Should basically follow from /DDINL toggling low after reset. > 7) EPROM's pin 20, /EPROM, appears to be continually enableed with a > pattern like: > ___ ____ ____ ____ ___ > | | | | | | | | > |_| |_| |_| |_| Ok, we are running in the EPROM. But, if /EPROM toggles low a lot, even after reset, then /DDINL should also toggling since we only do reads of /EPROM right? > 9) DUACLK @ ICU pin 32 and at each DUART pin 36 looks like a square > wave with period about 260ns. (This is good, right? Like, 1/3.6864 > gets us .271.) Yes this is good. > 10) /HSA out of U36 is 500ns square wave. > /RFCYC into U36 is 500ns square wave. > 1M4M at U36 pin 17 is 150ns squre wave. Questionable measurement here. Well, /HSA should go low for an in-page DRAM access (page mode). /RFCYC indicates that a refresh cycle is in progress. 500ns sounds totally wrong! We should get a /RFCYC at the same rate as the refresh requests, i.e. at 30usec. Hmm, please recheck. 1M4M is one of the address lines - anything is reasonably I suppose. > 11) Both QO0 and QO1 have activity sorta like: > _ _ _ _ > | | | | | | | | > ___| |__| |________| |__| |___ > > Pins 1 and 13 of U32 have ~150ns square wave input. Again questionable. Reasonable. They toggle during dram burst accesses. > 12) /RDY into CPU pin N11 has ~700ns period with 400ns low, ~300ns high. Pulling wait states, 400ns low is a bit long I would think. Are you running a 50MHz xtal? The long /RDY (not this long though) is for each EPROM access. > 13) /BMI blips low every 200ns. What is /BMI ??? You mean /BMT? If so, this is the first T-state of a bus cycle. If /RDY is low for 400ns then /BMT should cycle no faster than 400ns. But then you would have to look at both signals at the same time. > 14) /DDIN blips low every 200ns for 40 or 50 ns. Ditto for /DDIN. 40/50ns pulses indicate DRAM accesses - EPROM is a lot slower. Sounds like we are in the weeds - i.e. jumped into DRAM. > 15) /IOINH likes to be +5 at U37. /IOINH will only do things for I/O accesses when the on-chip 532 write fifo has data in it. It is reasonable that it is high most of the time. > 16) /IODEC appears to have an 800ns period mostly low with a 100 ns > high and a mere rising/falling edge on alternate 400 ns. /IODEC should go low and stay low during any I/O access. It will be high for EPROM and DRAM accesses. > 17) /SLOW looks like 800ns period with a 200ns high, 600ns low. This indicates that a slow device I/O is in progress - such as EPROM, or DUART accesses. Again 600ns low is very long - are you running a 50MHz xtal? > 18) /RAS into U31 pin 2 ~160ns period. > > 19) /RFRQI out of U39 has ~500ns period with most of it high. This is wrong. Check the refresh clock out of the ICU when you see this fast refresh activity, ditto for 10). > 20) /CASP and /NRDYP are elusive. They are active and then hold high. /CASP should pulse for the last part of any read/write access. /NRDYR will be asserted for any DRAM wait state. > 21) /BOUT at U39 pin 6 is 600ns cycle with 200ns low. This means a burst DRAM access is in progress. > 22) DRQS always low at U40 pin 18. > > 23) DRQS0 and DRQS1 always low at U40. Ok, since you don't have any SCSI activity. DRQ is a signal informing us that there is data request from the SCSI chips. > 24) I measured /CONF twice. The first time at U37 and got a > 150 ~ 160ns cycle with 100 high, 50 ~ 60 low. Second time around > at U40 pin 11 I got a 600ns square wave. The latter seemed to be > repeatable and confirmable, while the former did not. /CONF should be asserted for all and any valid bus cycle. > its memory or we crash the CPU. I would imagine I could watch the > data passing through the 646, for example. I'd have to corner someone > here to show how to work the fool thing. That might be the next step. Painful as it is! > Also, I didn't check the memory system much at all. Is it possible > that I crash when the monitor first tries to use RAM? I removed the > parity PAL U20 on the off chance it was confusing things. Nothing > seemed to change. Yes, all is possible right? Anyhow, do you have access to an EPROM programmer? I can get Dave to send you the binaries for a RAM-less monitor that we used to first bring the pc532 up (in the original wirewrap prototype). At least we can use it to determine if the DRAM is bad and causing the crash. best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies (408) 434-0600 3050 Zanker Road San Jose, CA 95134