I am not sure what you are driving at. For example, I usually write a testing program to test an algorithm or process. As one example, the first time I used a FIFO and linear RAM in a PIC, I self tested by loading and unloading it. I wouldn't include that in any final design as I don't do stuff that is life critical.Hi team
In the context or a MCU (no external ram), can we write some code to do some basic selftest, eg RAM and IOs? I am not sure if RAM selftest is necessary. But how do we selftest IOs?
Yes I was referring to bad hardware, eg dry joint or something. Not software bug testI am not sure what you are driving at. For example, I usually write a testing program to test an algorithm or process. As one example, the first time I used a FIFO and linear RAM in a PIC, I self tested by loading and unloading it. I wouldn't include that in any final design as I don't do stuff that is life critical.
Are you actually asking about checking for BADRAM (i.e., bad hardware)?
Thanks Paul, that's a very good reference for me to start dig deeper!We did FMEA selftests for MCUs in appliances, given that a misbehaving appliance could burn down a house.
FMEA = Failure Mode Effects Analysis.
First FMEA was done on the paper design to evaluate what would happen if two adjacent pins were shorted together, and whether that would be detectable in a bootup routine.
Second was a check of what would happen if any part was missing/opencircuit (can happen over time from cracked component or cracked/fried trace).
If the result of such a simple evaluations was catostrophic the MCU pinout was altered by reassigning IO pin positions.
For MCU the bootup test would check for any obvious shorts to adjacent pins (procedure bvelow). If such faults couldn't be detected at bootup then if possible the MCU pinout was altered by reassigning IO pin positions to try and improve the bootuip test coverage.
Basically this was the procedure on powerup:
a) For pins that were outputs you would first set them with a weak internal pullup or pulldown resistor (if MCU has internal pullups/pulldowns).
- Read all the pins to see if they gave appropriate highs/lows. If not then possibly there is a short to an adjacent pin.
b) Stepping though each output pin drive it high/low and each time check for changes in state of adjacent pins (shorts), Where possible check for correct feedback from controlled circuits (opens, wrong components).
c) Repeat for all pins that you can drive without damaging the unit.
This isn't exhaustive explanation by any means, but it can really help in Production Quality and in field diagnostics (The unit can display or log an error message or code on bootup if something incorrect, log to a file if USB or SD card type device in unit like an aircraft's black box).
Scan the internet for more detailed FMEA methods and design guidelines.
Paul
Could you swear that you tested everyhting?When I used to service minicomputers we had tests for CPU functionality and extensive memory tests.
Testing CPU was very thorough and extensive. The first test was the HALT instruction. Following that, every conceivable ALU and CPU operation was tested at the bit level. All possible branch conditions were tested.
Memory tests were also very extensive, all zeros, all ones, alternative zeros and ones, moving zeros and ones, random pattern, X/Y addressing cross patterns, read/write, sense amp cross effects, etc. A complete memory test suit on 16K words of RAM took hours to complete.
For modern MCU, you can do a simple checksum of firmware in flash memory, followed by read/write tests on RAM.
Testing HW modules and I/O will require much more effort.
Sorry, I don't swear.... but I give you my word.Could you swear that you tested everyhting?
Could you define sufficient in this context?This sequence would continue until a sufficient number of machine instructions were validated
http://bitsavers.org/pdf/univac/mil...31C_AN_UYK-20_Technical_Description_Nov76.pdfThe built-in microcoded diagnostic routine tests the basic micro instructions, control memory, I/O, lower 8K of memory, I/O instructions and the emulate instruction. The program loaded diagnostic routines are more comprehensive and can be loaded from external memory into computer memory as needed.
Just curious, why did you use a through hole part?Another thing about self-test is what happens when a system fails. Is there redundancy to keep the system safely running and/or is there a builtin backup for things like on-board power failures.
No special reason.Just curious, why did you use a through hole part?
by Jake Hertz
by Aaron Carman
by Aaron Carman
by Jake Hertz