Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news From: ian@sibyl.eleceng.ua.oz.au Newsgroups: comp.sys.nsc.32k Subject: Re: Hardware Problems Message-ID: <9006101632.1021@munnari.oz.au> Date: 10 Jun 90 15:20:57 GMT References: <> Sender: news@daver.bungi.com Lines: 64 Approved: news@daver.bungi.com George Scolaro writes: > [In the message entitled "Hardware Problems" on Jun 4, 12:51, ian@sibyl.eleceng.ua.oz.au writes:] > > My board occasionally gets into a stuck state, where "reset" fails to > > restart things. > > > > When it is in this state, the LED's are out and the CPU is stopped > > with /rdy high. It appears to stop in a write to the AIC6250 or at > > least with /scsi selected. I've measured the signals around the WAIT > > PAL a DVM which is not the most appropriate instrument, but its the > > best I have at home. Things have deteriorated! I can no longer talk to the serial port at all and the "stuck" state is now quite reproducable. What happens is this. On power up (or "successful" reset) the leds go out almost immediately and there are pulses on the icu select line for about 30sec. There are also pulses on the erom, and scsi lines for a much shorter period. The DUART never gets selected. During the 30 seconds there are pulses on the dram select line. After the 30sec the only thing that ever gets selected is the DRAM. Eventually (10minutes) the thing gets totally stuck with scsi selected and the cpu waiting for rdy. If I reset before the "stuck" state then the cycle is repeatable. If I wait until it is "stuck" then reset won't work and the only way out is to power off. The "stuck so it won't reset problem" seemed the easiest to attack so I investigated it further. It seems that reseting the wait pal from the "idlew" state is supposed to happen when the cpu starts its first bus cycle to the eprom. Well, /slow and /scsi can both be observed to momentarilly change state (to 0 and 1 respectively) when the reset is removed. I can't for the moment say whether that happens simultaneously. I've borrowed a logic probe but not a logic analyser yet! The eprom also gets momentarilly selected when reset is raised but that is about all that happens before it is stuck in the same "idlew" state as before! The swap signal is also high. My current hypothesis is that the select pal is dodgy. I will attempt to run the test vectors on all the pals tomorrow (don't actually know if our programmer will do that). I can't think of many hypotheses which let "reset" work when the system is in any state except "idlew". Other observations: When it was working, I *think* the monitor idle loop got totally cached and there where no dram accesses (except for refresh), so it is a bit strange that it now sits there accessing RAM. Of course, if it is slowly executing garbage until it hits the scsi select problem then I suppose that would explain why it is doing DRAM accesses, but maybe it is a sign that the chip select is broken. I have also tried removing the parity GAL but it makes no apparant difference. I have three eproms. The original monitor that came with the system, the most recent binary that Bruce posted and also a locally compiled version. They all exhibit this behaviour, so I am disinclined to think it is a eprom problem. I am for now assuming that the "can't talk to the duart" and "stuck so it won't reset" problems are symtoms of the same fault. Any suggestions are still very much welcome! Ian Dall. P.S. Should I discuss this directly with George or is there enough interest to warrant posting to the whole list?