Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news From: gs@vw25.chips.com (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: Hardware Problems Message-ID: Date: 4 Jun 90 17:29:46 GMT Sender: news@daver.bungi.com Lines: 71 Approved: news@daver.bungi.com [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. > > U38 > Pin Logic Level > ----------------------------- > 1 (ck) Pulsing (*) > 2 (/eprom) 1 > 3 (/scsi) 0 > 4 (/bmt) 1 > 5 (/ddin) 1 > 6 (/slow) 1 > 7 (drq) 0 > 8 (scsii) 0 > 9 (a22) 1 > 11 (/oe) 0 > 12 (/dack) 1 > 13 (/nrdy) 0 ] > 14 1 ] > 15 1 ] This indicates the IDLEW state in the wait pal. > 16 1 ] > 17 (/rd) 1 > 18 (/wr) 1 > 19 (/eop) 1 > > This fault is difficult to reproduce. This state is *after* I have pressed > reset, however, reset normally does the write thing. Is there some flip > flop somewhere which should be reset and isn't? I have no idea if this is > a design fault or a fault on my particular board. All ff's that should be reset are. The only things that are not are some of the state machines in the pals. These rely on getting into the 'reset' state, i.e. the idle state by clocking there. I have not seen the problem you are having - in fact the IDLEW state that the wait pal is in can only be reached by performing a read/write to the pseudo-dma port. If you look at the wait pal source you will see that once in the IDLEW state the only way to exit is via reset (ie !(!slow & scsi)) or if drq or scsii are asserted (which will never happen if you get into IDLEW by accident). The only way to get there is if a bus cycle when bmt & !slow & scsi & !drq & !scsii is true. This should never happen except for pseudo-dma scsi accesses. i.e. something is wrong! But if we look at the voltages that you have indicated are present: 1 1 0 0 0 bmt & !slow & scsi & !drq & !scsii Note: bmt is only asserted (low) in the 1st T-state of a bus cycle, so it would have been low initially (to get to the IDLEW state). The equation is true - which explains why you are in the IDLEW state. i.e. the wait pal is doing the right thing, but for some reason the EPROM boot code is doing the wrong thing. My bet is that the EPROM is flakey - if it is an AMD part then toss it and re-program it into a different part. We have had lots of trouble with AMD EPROMS - we had to return a whole bunch we bought for the PC532 kits. You may have got one of the few that 'appeared' to work. anyhow, keep us informed of your progress, - at last some hardware problem I can think about... p.s. measuring the signals on the wait pal was exactly the right thing to do. -- George Scolaro (gs@vw25.chips.com) Chips & Technologies +1 408/434-0600 X4556 work 3050 Zanker Road San Jose, CA 95134