Page 113 - The Art of Designing Embedded Systems

100 THE ART OF DESIGNING EMBEDDED SYSTEMS

InveHing Bits
Most diagnostic code uses the simplest of tests-writing alternating
0x55 and OxAA values to the entire memory array, and then reading the
data to ensure that it remains accessible. It’s a seductively easy approach
that will find an occasional problem (like someone forgot to load all of the
RAM chips), but that detects few real-world errors.
Remember that RAM is an array divided into columns and rows. Ac-
cesses require proper chip selects and addresses sent to the array-and not
a lot more. The OxWOxAA symmetrical pattern repeats massively all over
the array; accessing problems (often more common than defective bits in
the chips themselves) will create references to incorrect locations, yet al-
most certainly will return what appears to be correct data.
Consider the physical implementation of memory in your embedded
system. The processor drives address and data lines to RAM-in a 16-bit
system there will surely be at least 32 of these. Any short or open on this
huge bus will create bad RAM accesses. Problems with the PC board are
far more common than internal chip defects, yet the Ox55/OxAA test is sin-
gularly poor at picking up these, the most likely, failures.
Yet the simplicity of this test and its very rapid execution have made
it an old standby that’s used much too often. Isn’t there an equally simple
approach that will pick up more problems?
If your goal is to detect the most common faults (PCB wiring errors
and chip failures more substantial than a few bad bits here or there), then
indeed there is. Create a short string of almost random bytes that you re-
peatedly send to the array until all of memory is written. Then, read the
array and compare against the original string.
I use the phrase “almost random” facetiously, but in fact it hardly
matters what the string is, as long as it contains a variety of values. It’s best
to include the pathological cases, such as 00, Oxaa, 0x55, and Oxff. The
string is something you pick when writing the code, so it is truly not ran-
dom, but other than these four specific values, you fill the rest of it with
nearly any set of values, since we’re just checking basic writehead func-
tions (remember: memory tends to fail in fairly dramatic ways). I like to
use very orthogonal values-those with lots of bits changing between suc-
cessive string members-to create big noise spikes on the data lines.
To make sure this test picks up addressing problems, ensure that the
string’s length is not a factor of the length of the memory array. In other
words, you don’t want the string to be aligned on the same low-order ad-
dresses, which might cause an address error to go undetected. Since the
string is much shorter than the length of the RAM array, you ensure that it