Software-Based Memory Testingby Michael Barr If ever there was a piece of embedded software ripe for reuse it is the memory test. This article shows how to test for the most common memory problems with a set of three efficient, portable, public-domain memory test functions.[ Introduction | Common Problems | Test Strategy | Data Bus | Address Bus | Device | Put it together ] |
|
|||||||||
|
One piece of software that nearly every embedded developer must write at some point in
his career is a memory test. Often, once the prototype hardware is ready, the board's
designer would like some reassurance that she has wired the address and data lines
correctly, and that the various memory chips are working properly. And, even if that's not
the case, it is desirable to test any onboard RAM at least as often as the system is
reset. It is up to the embedded software developer, then, to figure out what can go wrong
and design a suite of tests that will uncover problems. At first glance, writing a memory test may seem like a fairly simple assignment. However, as you look at the problem more closely you will realize that it can be difficult to detect subtle memory problems with a simple test. In fact, as a result of programmer naiveté, many embedded systems include memory tests that would detect only the most catastrophic memory failures. Perhaps unbelievably, some of these may not even notice that the memory chips have been removed from the board! The purpose of a memory test is to confirm that each storage location in a memory device is working. In other words, if you store the number 50 at a particular address, you expect to find that number stored there until another number is written to that same address. The basic idea behind any memory test, then, is to write some set of data to each address in the memory device and verify the data by reading it back. If all the values read back are the same as those that were written, then the memory device is said to pass the test. As you will see, it is only through careful selection of the set of data values that you can be sure that a passing result is meaningful. Of course, a memory test like the one just described is necessarily destructive. In the process of testing the memory, you must overwrite its prior contents. Since it is generally impractical to overwrite the contents of nonvolatile memories, the tests described in this article are generally used only for RAM testing. However, if the contents of a non-volatile memory device, like flash, are unimportant-as they are during the product development stage-these same algorithms can be used to test those devices as well. [ Introduction | Common
Problems | Test Strategy | Data Bus | Address Bus | Device | Put it together ] |
ESAcademy, 2000 All materials |