While tests 1, 2, 3, 6, 7, 8, 9, and 10 might be used in an "incoming inspection spot-check, or the like, it doesn't seem that they're necessary for POST. Test 5, too, is not particularly useful for POST, unless you use external memory, though it should be spot-checked, say at a 5-10% sampling with each lot at receiving inspection. Once the MCU is soldered in place, the only thing that needs to be checked is the ROM checksum. If that fails, the entire product is likely to be tossed out since an MCU failure of any sort, at least in the context of tests 1 .. 9 will likely cause the checksum to fail as well.

POST should identify detectable errors specific to the system. If you install a "broken" MCU, it's not easy to detect that in a normal sort of POST. If you have the time at power-on, you could to this extensive testing, but, where do you stop? Are you willing, beforehand, to perform a complete failure mode and effects analysis? If you detect a checksum error in code space, how do you know whether it's a bad accumulator bit, or a bad memory addressing path, or a bad ALU? Does it matter?

If you system communicates with something else, does it have a valid initialization message? Do you have facilities for hardware loopback? How would you go about checking your hardware port function? Are you willing to include hardware support for such testing?

Food for thought!

RE