Catastrophic failures are uncommon and usually affect large portions of the chip. This is usually caused by some sort of physical or electrical damage to the chip after manufacture. The one type of memory chip problem you could encounter is a catastrophic failure. If there is a problem with a particular batch, it is extremely unlikely that one of the bad chips will make its way into your system. The manufacturers of memory devices perform a variety of post-production tests on each batch of chips. Though a major issue at one time (a few decades ago), problems of this type are increasingly rare. One common misconception among software engineers is that most memory problems occur within the chips themselves. Common Memory Problemsīefore implementing any of the possible test algorithms, you should be familiar with the types of memory problems that are likely to occur. 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. 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. In the process of testing the memory, you must overwrite its prior contents. Of course, a memory test like the one just described is necessarily destructive. 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. If all the values read back are the same as those that were written, then the memory device is said to pass the test. 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. 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 purpose of a memory test is to confirm that each storage location in a memory device is working. Perhaps unbelievably, some of these may not even notice that the memory chips have been removed from the board! In fact, as a result of programmer naïveté, many embedded systems include memory tests that would detect only the most catastrophic memory failures. 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. 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.Īt first glance, writing a memory test may seem like a fairly simple assignment. 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. 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. One piece of software that nearly every embedded developer must write at some point in his career is a 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. If ever there was a piece of embedded software ripe for reuse it is the memory test.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |