in your http://www.8052.com/forum/read.phtml?id=131082 you address questions of testing passives, regulators, etc, when what's needed is a generalized test of the 805x MCU and internal and external memory associated with it, and the internal facilities, i.e. serial ports, counter/timers, and parallel port pins. I'm not suggesting that one test all the external hardware, but, rather, one verify that the device, the MCU, have the ability to address its external hardware if there is any. After all, I'm referring to hardware that's just been received, and hasn't been put into stock yet. One can test random samples, or one can test all of the parts, but one doesn't want to end up in a situation like mine, where some parts that were accepted as "probably OK" from a distributor years ago and are now needed but half a dozen of the first ten parts don't work in the application for which they were purchased.

The first thing that should disturb one is the fact that some behave one way, and other behave differently. The second is that some function in a sound application while others don't.

The purpose of incoming inspection is to prevent the distributor from foisting his rubbish off on you. If you don't care about that, i.e. if you're willing to risk spending hours, days, or weeks figuring out why a replacement part, or a new installation doesn't function as expected, then you can probably skip incoming inspection. If you think it's adequate to "try out" a couple of samples, then that's probably valid. However, I'm currently rethinking my long-outdated policy of more-or-less trusting distributors, with whom I've never been particularly happy anyway, and behaving more along the lines of "once-bitten, twice-shy," as the saying goes.

What's more, it would be worthwhile, IMHO, to have a tool by means of which one could ascertain whether a given specimen of a device was in good health.

Since CMOS 805x's are static, I'm persuaded that it would be possible to collect samples of the pin states on the device and compare them with what was expected, i.e. establish a set of test vectors and use them in that mode. Internals can be checked in this way, too, by jamming instructions to cause the MCU to cough up its internal state. This can settle questions about whether the MCU is the cause of the trouble, but it won't be a 2 ms test.