> H.C. Croon wrote: > > >>Hello Declan, > >> > >>Will someone with a little testing savvy explain the basics of guarding > >>to me. > >> > >> > >Guarding is shielding with a shield which is actively hold on an > >appropriate voltage. When you have a small differential signal (p.e. > >EEG) with a high common mode voltage, you can give the shield the > >common mode voltage in order not to capacitively load the signal. > >This common mode voltage can be obtained from the instumentation > >amplifier which amplifies the signal. > >So, in my opinion, guarding is not the right answer to your problem. > > > >As for your problem: I suppose you found and used the digital ground > >of the board. Which things fail? Can it be that RESETting the CPU, > >puts the output pins in an open state (3-state outputs?). > >As you say the board is "known to work" what is you aim in testing? > > > > > You're right Harry, That's not what I was talking about at all. > > The term is also used in board testing, when one is finding faults at > component level. If you want > (as I do) to in-circuit test chips, some will fail because they are > already being driven by other > devices on the board. No shields are in sight. > > In struggling with my new toy (a fancy diagnostic kit) I started with > 100% fails on functional tests, and am > slowly progressing . The smart alec who was using it last disabled > functional testing, but that's the big thing I > was wanted to tame.. > > For example, let us say I am working on a board fitted with a Z80 or > similar cpu, and support chips > All support chips will share the power lines, /RD, /WR, the databus and > at least some of the address bus.. To > check a ram chip with in circuit testing, I will have to prevent every > other chip from talking on the > buses. Because as soon as such a ram chip is poowered, so is the and the > rest of the board. It was > this 'guarding'I was trying to enquire about. Guards (links to 0V or +5V > as appropiate) would be clipped > on to tristate or otherwise disable the other devices on the databus. > It's a black art., and apparently not always > possible.
OK, that a signification which is new to me. > > With 74HC, this is more difficult, as 74HC is driven high, as opposed to > 74LS which simply floats high. With the exception of open collector drivers TTL has totem pole outputs, so it sinks as well as sources output current. It is however short circuit proof, so your method holds. I am not sure whether 74HCxxx is fully short circuit proof. Perhaps the datasheet will affirm it. > I would feel safe pulling down 74LS outputs., but am a little cagier > about pulling down(or up) 74HC outputs. > > Future lessons in store for me include cross compiling and perhaps even > writing specific test programs for > devices not in the device library. So, you have a nice "toy" and in the work you are doing can save you a lot of time. Your time investment of this moment will render his yield somedays. So long, Harry > > > > -- > Author: Declan Moriarty > INET: [EMAIL PROTECTED] > > Fat City Hosting, San Diego, California -- http://www.fatcity.com > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB CHIPDIR-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Author: H.C. Croon INET: [EMAIL PROTECTED] Fat City Hosting, San Diego, California -- http://www.fatcity.com --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB CHIPDIR-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
