ian@sibyl.eleceng.ua.oz.au (06/04/90)
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
16 1
17 (/rd) 1
18 (/wr) 1
19 (/eop) 1
* I measure an intermediate voltage so I presume there is clock present.
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.
Ian Dallgs@vw25.chips.com (George Scolaro) (06/05/90)
[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
news@daver.bungi.com (06/05/90)
> > 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 [stuff deleted] A long-shot, but the problem kinda sounds like the one I had. In my case, I did not have the 32532 __fully__ seated and as a result some signals (which unknown) were intermittent. johnc --
ian@sibyl.eleceng.ua.oz.au (06/10/90)
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?
george@wombat.bungi.COM (George Scolaro) (06/11/90)
[In the message entitled "Re: Hardware Problems" on Jun 11, 1:20, ian@sibyl.eleceng.ua.oz.au writes:] > > 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 As John Connin mentioned, have you ensured that the 32532 is fully seated in it's socket. There are 4 pins (near each corner of the chip) which have small rings that should seat all the way flush with the socket. The 32532 should be pushed all the way it until this occurs - it does take a lot of pressure - i.e. place the board flat on something a bit soft (several sheets of newspaper) and then stand over the board and with the palm of the hand PUSH until the chip is fully seated (if you ever have to extract the 32532 you will discover the wonders of splintering ceramic - unless you have a PGA chip extractor!). > 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. You definitely have some major problem - a dead chip or bad contact. > 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 /SLOW is asserted for all slow devices - i.e. checking the DEC32 equations: SLOW = EPROM (in both swapped and non-swapped positions) # duart (all 4) # scsi (software polled only - Not pseudo-dma) # icu. > 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 Obviously the thing to check is that /SCSI should be asserted along with /SLOW when the monitor is programming the AIC chip to turn the LEDs on. If /SLOW isn't asserted then the WAIT pal is not at fault - it's doing what it should be - and the fault is the code being executed by the 32532 - data path or control problem to/from the EPROM-32532. > but that is about all that happens before it is stuck in the same > "idlew" state as before! The swap signal is also high. Again, the only way this can happen is if /SCSI is asserted and the /SLOW is not. This is only for pseudo-dma accesses which are not present in the monitor (at least not at the boot/signon phase). This means that the cpu is executing incorrect code. Maybe the WAIT pal is broken - or something that controls the EPROM-CPU data path access. Since this is a rock hard reproduceable problem you should attack it from there. > 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". The SELECT pal shouldn't be able to cause the problem you are seeing, unless it is selecting the AIC or 8490 device (via their chip selects) continuously and therefore causing data bus contention etc. The monitor code will still fire up if you pull the AIC, 8490 and SELECT pal out - maybe you should also try that. > 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. Agreed, the EPROMs themselves are not at fault. > 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. Definitely - whatever is causing the pseudo-dma access instead of a normal programmed access to the AIC chip is at fault. best regards, -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]
ian@sibyl.eleceng.ua.oz.au (06/13/90)
George Scolaro writes: > [In the message entitled "Re: Hardware Problems" on Jun 11, 1:20, ian@sibyl.eleceng.ua.oz.au writes:] > > > > 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 > > As John Connin mentioned, have you ensured that the 32532 is fully seated > in it's socket. I think so. > There are 4 pins (near each corner of the chip) which have > small rings that should seat all the way flush with the socket. I can't see any rings on *my* 32532. However, I used the method you suggested and applied a *lot* of force -- my full weight which is 95kg. I am unwilling to use any more force than that! To quantify, there is a .6 - .7 mm gap between the ceramic of the pc532 and the top of the socket (I measured with feeler gauges)! This is the same or slightly less than the gap for the 32381. > (if you ever have to extract the 32532 > you will discover the wonders of splintering ceramic - unless you have a > PGA chip extractor!). I shudder to think. The thought crossed my mind as I pushed it in that I hope I never have to extract it! It does beg the question, what use is a socket that you can only plug in once to? I attempted to verify the PALS. Well it turns out that I can verify PALs but not GALs (which most of them in fact are). So I blew a new decoder PAL and plugged it in. Lo and behold it worked! Being the suspicious sort, I plugged the original back in and it still worked! Strange. While it was working I deliberatly got it into the "idlew" state by accessing location 3800 0000 with the rom monitors dump and set commands. Sure enough it ground to a halt. It then takes *two* resets to get the prompt back. Can you please check this? It was quite repeatable. Clearly I hadn't actually fixed anything but maybe there was an intermittent dry joint near the socket, so I pulled the board out, and resoldered that socket. Now it doesn't work again in exactly the same way as before and with either PAL. Poking around the decoder PAL reveals a strange anomaly. /ioinh is permanantly high and yet I get pulses out of /icu. This, according to the PAL equations, is impossible! The only explanation I can think of is that there *are* pulses on /ioinh which are two short for the logic probe and which get stretched going through the PAL. This still doesn't seem very likely, the probe detects pulses on bclk and /bclk perfectly well. I also thought that maybe there was a bad connection to the 532 on that pin. However, removing the DEC32 PAL shows that the /ioinh pin is still high. The only explanation for that is that the 532 is driving it that way! When should the 32532 assert /ioinh? My reading of the manual implies that it should get asserted for every bus read. Is there anything which can prevent /ioinh being asserted? Note that the CPU is active with address lines waggling up and down and /conf waggling up and down. As Alice said "curiouser and curiouser". Ian Dall.
gs@vw25.chips.com (George Scolaro) (06/13/90)
[In the message entitled "Re: Hardware Problems" on Jun 13, 3:16, ian@sibyl.eleceng.ua.oz.au writes:] > > I can't see any rings on *my* 32532. However, I used the method you > suggested and applied a *lot* of force -- my full weight which is > 95kg. I am unwilling to use any more force than that! Sounds like it is definitely seated properly - since you can't see the rings. > I shudder to think. The thought crossed my mind as I pushed it in that > I hope I never have to extract it! It does beg the question, what use > is a socket that you can only plug in once to? With the correct chip extractor (which looks like a medieval thumb screw) it is quite an easy task. The reason the socket is so tight is that I neglected to get very low insertion force pins! Oh well. > decoder PAL and plugged it in. Lo and behold it worked! Being the > suspicious sort, I plugged the original back in and it still worked! Hmm, an intermittent of some sort - that's for sure. Maybe you should check (if you haven't done so) that no chip legs are bent under in their sockets. Also 'wiggle' the board while resetting to see if it comes to life. Also, check the resistor packs (the SIPs primarily), I have seen them with hairline cracks that cause all sorts of nasty intermittent problems. > commands. Sure enough it ground to a halt. It then takes *two* resets > to get the prompt back. Can you please check this? It was quite > repeatable. I have seen this sort of thing. Even though the pal should come out of the IDLEW state, I think that the 532 gets 'confused' on the first new access. Anyhow - I'm not sure why it takes 2 resets, but that is normal behaviour when it crashes in this way. > resoldered that socket. Now it doesn't work again in exactly the same > way as before and with either PAL. The fault must be at some other place - that causes the IDLEW state lockup. > Poking around the decoder PAL reveals a strange anomaly. /ioinh is > permanantly high and yet I get pulses out of /icu. This, according to > the PAL equations, is impossible! The only explanation I can think of No, the I/O access is inhibited if /IOINH is low. i.e. it should be high for a valid I/O access to proceed. > /ioinh pin is still high. The only explanation for that is that the > 532 is driving it that way! Yes it is - i.e. it is correct for /IOINH to be normally high. > When should the 32532 assert /ioinh? My reading of the manual implies that > it should get asserted for every bus read. Is there anything which can No. /IOINH means I/O inhibit. The only time the 32532 does this is if there is a pending write (i.e. in it's on-chip write fifo) and you are trying to do a read access. /IOINH is asserted to tell the hardware that if the current access is to an I/O device then it should be ignored. At the same time the hardware should generate /IODEC (set it low) to inform the 32532 that the current access really was to an I/O device. The 32532 will then flush out the write fifo and re-execute the aborted read access (this time not asserting /IOINH). These events are essential to ensure that a write to a I/O control port followed by a read from the I/O device (e.g. while setting up a UART) executes in the correct order. I'm pretty sure that NS has a patent on this protocol. The 486 etc can get away with not having this stuff since it has dedicated I/O instructions - the 32532 has no special purpose instructions for handling I/O so it needs this extra hardware - of course you get a more powerful instruction set to do I/O with. > As Alice said "curiouser and curiouser". But at least everything still makes sense.... best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies +1 408/434-0600 X4556 work 3050 Zanker Road San Jose, CA 95134
des@musashi.wpd.sgi.com (Des Young) (06/13/90)
Hmm, this is beginning to look like shorted pins/wires. May pay to check adjacent wires are not shorted, say adjacent pins on the PAL. A solder bridge between two traces can do it. Give the PCB a good scrub with a stiff brush on the back. Des. trademarks abound, usual disclaimers apply, opinions are mine des@pei.com Des Young (415) 335-1888 Protocol Engines Inc., Mountain View, CA
ian@sibyl.eleceng.ua.oz.au (06/13/90)
George Scolaro writes: > > Poking around the decoder PAL reveals a strange anomaly. /ioinh is > > permanantly high and yet I get pulses out of /icu. This, according to > > the PAL equations, is impossible! The only explanation I can think of > > No, the I/O access is inhibited if /IOINH is low. i.e. it should be high > for a valid I/O access to proceed. Sorry. I often get confused with negative logic. The problem is no doubt just a bad connection somewhere, but where is a bit tricky. I am running out of things I can test with a logic probe. If I haven't fixed by this weekend I'll take it into Uni and use a logic analyser on it. I have been a bit reluctant to do that because of the difficulty of attaching probes to either the PGA chips or the PLCC chips. Still, the ROM, the PALS and the buffers should provide access to most interesting signals. Ian Dall
news@daver.bungi.com (06/13/90)
Suggestions:
1) If you have not done so, decrease the processor clock frequency
(ie XTALM - U25) from 50 Mhz to say 20 Mhz.
2) Using a magnifier carefully examine each component and all solder
joints.
3) Push, pull, shove each component while running.
johnc
-- ian@sibyl.eleceng.ua.oz.au (06/14/90)
I *think* it is fixed now. I found a dry joint on U22. The +5 I think it was. Don't ask me how that caused the problem! The power supply and ground pins need quite a lot more heat than the signal pins due to the large amount of copper attached to them. I noticed this when I was soldering but I guess I didn't quite give this one enough. I hope that was all that is wrong (keeps fingers crossed)! Thanks for the help, Ian Dall
kevin@latcs1.oz.au (Kevin James Bertram) (06/15/90)
In article <9006101101.AA05461@wombat.bungi.COM>, george@wombat.bungi.COM (George Scolaro) writes: > PUSH until the chip is fully seated (if you ever have to extract the 32532 > you will discover the wonders of splintering ceramic - unless you have a > PGA chip extractor!). Sorry if this seems irrelevant but - I have found that anything wooden will prevent splitering when extracting PDA's. Something like a wooden rule. Pencils can't stand the pace. -Kevin (Kevin@latcs1.oz)
Steven.D.Ligett@mac.dartmouth.edu (06/16/90)
--- Ian Dall wrote: The power supply and ground pins need quite a lot more heat than the signal pins due to the large amount of copper attached to them. I noticed this when I was soldering but I guess I didn't quite give this one enough. --- end of quoted material --- Congratulations! I hope you've got it! At Dartmouth, we build a lot of our own hardware for our communications network. The shop technicians build the boards at home for overtime. Usually, I just give them a bag of parts, a blank board, and a board to copy. My only instructions are "More heat; less solder." You don't want joints with blobs of solder, you want joints where the solder has wicked up into the hole. If you're soldering sockets, it impossible to see how the joint looks on the top. If you're soldering chips straight into the board, you can look for a hole filled with solder, and a fillet on the top and bottom side. Frankly, you probably can't do it consistently on the power and ground pins. Or maybe, frankly, *I* can't do it on a board with power and ground planes. If a joint looks bad, don't just blob more solder on it, remove the old solder, and try again.
gs@vw25.chips.com (George Scolaro) (06/16/90)
[In the message entitled "Re: Hardware Problems" on Jun 15, 13:17, Steven.D.Ligett@mac.dartmouth.edu writes:] > --- Ian Dall wrote: > The power supply and ground pins need quite a lot more heat than the > signal pins due to the large amount of copper attached to them. I > noticed this when I was soldering but I guess I didn't quite give this > one enough. > --- end of quoted material --- > Congratulations! I hope you've got it! > > At Dartmouth, we build a lot of our own hardware for our communications > network. The shop technicians build the boards at home for overtime. > Usually, I just give them a bag of parts, a blank board, and a board to copy. > My only instructions are "More heat; less solder." You don't want joints with > blobs of solder, you want joints where the solder has wicked up into the hole. Very true. Most of the ground and power pins on the PC532 use thermal reliefs. That means that the pin is not 100% connected to the copper plane but instead has small pie sections (4 of them) in each quadrant that don't contain copper. The thermal relief is intended to enable a good solder joint to be made on a wave solderer - where consistent joints are essential on all pins at a given solder temperature. For manual soldering, I generally like to have the tip well tinned and then bring it down on the pin/pad that I am about to solder. I leave it there for 1/2 or so before adding the solder. This ensures that the pin and pad/hole are heated and the solder wicks nicely down the hole. A 'nice' solder joint will always be shiny. Even though it takes a bit of work it is a good idea to clean the flux off the board after soldering with one of the commerial flux removers. Then it is much easier to inspect your handywork. The flux (resin) in electronics grade solder will not cause corrosion of the traces and pads - the reason to remove it is to make the board like 'nice' and to be able to inspect the joints. Ditto on the congats. best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies (408) 434-0600 3050 Zanker Road San Jose, CA 95134
gs@vw25.chips.com (George Scolaro) (06/16/90)
[In the message entitled "Re: Hardware Problems" on Jun 15, 3:45, Kevin James Bertram writes:] > Sorry if this seems irrelevant but - > > I have found that anything wooden will prevent splitering when extracting > PDA's. Something like a wooden rule. Pencils can't stand the pace. Yes, but the 32532 when fully seated is really in to stay. The wood would have to be petrified to be able to remove the 32532 without itself splintering. regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies (408) 434-0600 3050 Zanker Road San Jose, CA 95134
bdale@col.hp.com (Bdale Garbee) (06/16/90)
> [In the message entitled "Re: Hardware Problems" on Jun 15, 3:45, Kevin James Bertram writes:] > > Sorry if this seems irrelevant but - > > > > I have found that anything wooden will prevent splitering when extracting > > PDA's. Something like a wooden rule. Pencils can't stand the pace. > Yes, but the 32532 when fully seated is really in to stay. The wood would > have to be petrified to be able to remove the 32532 without itself > splintering. I second the motion for a real PGA extractor when one is available... ...but apparently unlike many others on the list, I *have* been able to remove 175+ pin PGA's with metal screwdrivers without breaking anything. The key is to have about 6 screwdrivers and as many hands... even pressure all around... I end up doing 68pin PGA's routinely, so maybe it's just a matter of practice (being used to the frustration? :-) "These are trained professionals. Do not attempt this at home." :-) Bdale
neil@dvinci.UUCP (Neil Johnson,132L,6078,3825591) (06/16/90)
You could also try cold spray. A can costs about $10, and lasts for a couple of minutes. Spray suspicious chips/resistor packs/capacitors, etc for a few seconds. You want to cool the component, but do not want a lot of frost. The temperature change may cause a marginal part to start working or stop working. If a component consistantly changes the operation of your system when sprayed try replacing it. This can also be used to detect cracked traces. By the way, add one more board to the list of running systems. I had one screw-up during construction - I got the 68 pin PGA socket and LCC socket soldered in each other's place. I wrecked the PGA socket unsoldering it, but reused the leadless one. Luckily, the board worked the first time I applied power. Neil Johnson neil@skatter.USask.Ca