Well, that's how I've addressed this one, at least where that manufacturer is concerned.

Manufacturers aren't concerned with the parts your distributor ships you. That's true here and it's probably true there. They test a few samples, once they have a part in production, and, if they're O.K. they assume the rest of the lot is, too.

Distributors in the U.S. are totally unscrupulous, and will ship you, the small quantity purchaser, rejects from a large-quantity purchaser. It happens all the time. That's why one has to have incoming inspection. You have to be comfortable that what you've ordered and paid for, namely fully functional parts, is what you get. If you don't have incoming inspection, they can ship you whatever they want, so long as the invoice reflects what you ordered. If you find they're defective, you have no recourse, other than to return them to the distributor, if he'll replace them. You can't sue him, because you can't prove that this lot was previously shipped elsewhere and rejected.

If, on the other hand, you are concerned about what's coming in the front door, you look at it. That involves occasionally, or, in some cases, always, checking the devices for function.

If you receive 10 rolls of SMT components, don't you verify that they're correctly marked? It's unlikely that you'll be sent a roll with multiple values on it. Don't you verify that the quantity is correct? If you pay for 5000 parts, don't you expect that there will be that many on the roll?

If you receive 100 MCU's, don't you look to see what's on the invoice is also what's in the rails? Don't you take one or two out and put them in a circuit to ensure that they're functional? That's the step that interests me. If I have three malfunctioning MCU's, from a batch of 25, I want to know why. It doesn't mean that I'm concerned because I use 1000 a week, it's because I don't want my distributor to believe he can send me somone else's floor-sweepings. U.S. distributors brag about how they've done that.

I don't trust 'em. Our late president Ronald Reagan said, of the Soviets, "trust, but verify." That's what I want to do ... verify.

The MCU can't tell whether the pullup on its port is 1K or 10M ohms. However, it knows whether it "sees" external memory. It "knows" whether it read the value it last wrote to an internal location. It can "see" whether it received what it sent on its serial port. Today, if you want your money back from a distributor who sent you defective parts, you have to prove it. If you put some parts in a circuit and they function properly, and you put other, purportedly identical parts in and they don't, you have evidence. If you want to know your parts are fully functional, you have to have at least a minimal environment that enables you to verify that. One part of that enviroment is the code that will perform that function.

What I asked was whether anyone has written such code and used it. Back in the days when microprocessor technology was new, there were memory tests, instruction execution tests, etc, written and published in considerable volume. While it's true that a malfunctioning MCU can't be depended upon to produce reliable results in testing itself, all it should take is one isolated instance of such a failure to rule out the use of any individual sample from a given lot. It should also encourage further detailed testing of that lot before lots of time and effort are required to figure out why the boards containing members of that lot are "behaving peculiarly."

That's what concerns me ... as our willingnes to trust increases, the need for us to verify increases.

RE