how to do self test of microcontroller 8051

To be able to test itself, the microcontroller must be working; if it isn't working, it won't be able to test itself!

That's what I used to think.

But it is possible to write CPU tests to determine whether a sequence of instructions produces a correct result, and determine if various functional blocks (ALU, shifter, addressing, etc) of the CPU are indeed working correctly. Whether the failure is due to the functional block under test, or due to a problem with the execution unit still results in an error in calculating the correct signature patterns. "Working / not working" is exactly the result you are looking for, not the reason why the CPU isn't working.

If the CPU is completely borked, and you can't even execute an instruction, then further tests are pointless. But this is also an obvious problem. The question here is detecting more subtle errors in cores embedded into other products, that might have a small defect in just one part of the CPU core. Embedded self-testing can save the addition of lots of extra test logic on the chip, or, if you have a fast processor, even save time compared to external test devices.

Reliability only comes into play after you know the part already works. Here, I'm talking about the original manufacturing tests to determine whether that particular die should be sold, or tossed on the scrap heap. Once you know the chip is good, the likelihood that it will fail in the future may be so low that you don't bother with built-in tests for the final product containing the part, but you still need to somehow test the original die for defects before selling the part.

Here's a couple of references to papers on this sort of testing:

http://sigda.org/Archives/ProceedingArchives/Date/papers/2002/date02/pdffiles/06d_1.pdf

http://www.utdallas.edu/~nourani/Research/signal_integrity/scientia_03.pdf

To be able to test itself, the microcontroller must be working; if it isn't working, it won't be able to test itself!

That's what I used to think.

But it is possible to write CPU tests to determine whether a sequence of instructions produces a correct result, and determine if various functional blocks (ALU, shifter, addressing, etc) of the CPU are indeed working correctly. Whether the failure is due to the functional block under test, or due to a problem with the execution unit still results in an error in calculating the correct signature patterns. "Working / not working" is exactly the result you are looking for, not the reason why the CPU isn't working.

If the CPU is completely borked, and you can't even execute an instruction, then further tests are pointless. But this is also an obvious problem. The question here is detecting more subtle errors in cores embedded into other products, that might have a small defect in just one part of the CPU core. Embedded self-testing can save the addition of lots of extra test logic on the chip, or, if you have a fast processor, even save time compared to external test devices.

Reliability only comes into play after you know the part already works. Here, I'm talking about the original manufacturing tests to determine whether that particular die should be sold, or tossed on the scrap heap. Once you know the chip is good, the likelihood that it will fail in the future may be so low that you don't bother with built-in tests for the final product containing the part, but you still need to somehow test the original die for defects before selling the part.

Here's a couple of references to papers on this sort of testing:

http://sigda.org/Archives/ProceedingArchives/Date/papers/2002/date02/pdffiles/06d_1.pdf

http://www.utdallas.edu/~nourani/Research/signal_integrity/scientia_03.pdf

The question here is detecting more subtle errors in cores embedded into other products, that might have a small defect in just one part of the CPU core. Embedded self-testing can save the addition of lots of extra test logic on the chip, or, if you have a fast processor, even save time compared to external test devices.

I see, but that is hardly self-test since it requires an testbench setup.

I believe(d) - maybe the original poster will enlighten us - that the question referred to production units.

Erik