Micro2000 Home - PC Diagnostics and Systems Network Management  

Micro-Scope e-book


Memory Testing Pitfalls

There are some engineering considerations that are peculiar to memory testing. You don’t necessarily have to know these to test your memory, but you might find them interesting, and it’s definitely worth knowing when considering the features in Micro-Scope.

System Cache Memory – The idea behind cache is that you have a small amount of higher-speed (but more expensive) memory right next to the CPU, and the system tries to anticipate what RAM contents the CPU will want next and have those waiting in the cache. The CPU gets data from the cache rather than system RAM whenever it can, because it’s faster. There are two approaches to making this work. One assumes that the CPU will access the same data again, so the cache is filled with whatever the CPU has been using most recently. The other idea is called ‘look-ahead’ cache and it assumes that data is used in blocks, so whatever location is being accessed, the following locations are what will be needed next. Most systems use some balance of these two methods.

Cache speeds up system performance beyond a doubt, but must be circumvented in a memory test to be sure you are testing a particular RAM cell and not the cache chip. For instance if you want to test a block of memory addresses, as soon as the first address is accessed the following addresses are loaded into cache and CPU will access them in the cache rather than in system RAM. The RAM is not being tested at all, except for the first address.

There are two ways around this problem. On 486 and later processors, there is a CPU instruction to ‘invalidate’ the cache. This tells the processor that the cache is incorrect or ‘invalid’ and that the next read must be done from system RAM, not from the cache. However, running an extra command after every read makes for a very lengthy test. A better way to solve it is to fill all of the memory area with the test pattern before reading it, so that all of the original values have been moved out of the cache. This works well for extended memory, because there is much more system RAM than there is of cache memory. This is not necessarily true for Base Memory though, because many systems have more than 640KB of cache. For Base Memory, the only choices are to run the Invalidate Cache command after every read or have the user turn off caching in CMOS before running the test.

Line Charges – This has nothing to do with American football. A line charge is the residual electrical field that remains for a short time on a signal line and makes it appear that the signal is still there. This applies to memory testing because if a location is read too quickly after it is written, the data lines are still charged with the correct value and any timing or refresh errors may be masked. This can be easily avoided by not reading the same location immediately after writing to it, but the problem has to be understood and accounted for in the design of the test.

Restoring Memory – Although sloppy test designers can (and often do) ignore the previous two situations, they all have to deal with this one. Even while the test is busy writing and reading its own values from various RAM locations, there are certain RAM contents, especially in base memory, that must be preserved and then properly restored in order for the test program to continue running and for the operating system not to crash.

This is actually less of a problem with Micro-Scope and its bootable operating system, because we allow you to boot to the Base Memory test, or to the full diagnostic with multiple memory tests for everything except base memory, but you can’t do both at the same time. For those of you who stayed awake nights wondering why we did it that way, now you know.

To follow up last week’s tech tip that discussed the general principles of memory testing - this week we will look at the specific tests available in the Micro-Scope diagnostic.




 © 2005 Micro2000 UK  All Rights Reserved. Contact Us