Hi all iam working on the cygnal microcontrollers c8051f124, actually i have to perform self check of microcontroller on power on i have written some routines for RAM and how self check the cpu of microcontrollers ie i have to check the registers and cip 51 if any one having ideas please reply REGARDS nEiL
The idea of self test was relevant when the king of diamonds were a jack. The reliability of electronic components these days make a self test an anachronism. The testing that should be done at power up (if any) should not be of the uC but of certain system features. One example: If a valve being open at power up is dangerous a sensor (not the signal controlling the valve) should be interrogated to see if the valve is open and means take to shut the valve and, if unsuccesful, an alarm should be sounded. Testing the uC by itself serves no purpose. Erik
"Testing the uC by itself serves no purpose." And is, almost by definition, nigh-on impossible! To be able to test itself, the microcontroller must be working; if it isn't working, it won't be able to test itself!
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