Page 116 - The Art of Designing Embedded Systems

Firmware Musings 103

Other addresses often exhibit similar pathological behavior. Try
0x5555 and Oxaaaa, which also have complementary bit patterns.
The trick is to write these patterns back-to-back. Don’t test all of
RAM, with the understanding that both OxoooO and Oxffff will show up in
the test. You’ll stress the system most effectively by driving the bus mas-
sively up and down all at once.
Don’t even think about writing this sort of code in C. Any high-level
language will inject too many instructions between those that move the bits
up and down. Even in assembly the processor will have to do fetch cycles
from wherever the code happens to be, which will slow down the pound-
ing and make it a bit less effective.
There are some tricks, though. On a CPU with a prefetcher (all x86.
68k, etc.) try to fill the execution pipeline with code, so the processor does
back-to-back writes or reads at the addresses you’re trying to hit. And, use
memory-to-memory transfers when possible. For example:

mov si, Oxaaaa
mov di, 0x5555
mov [si], Oxff
mov [dil, [si1 ; read ffOO from Oaaaa
; and then write it
; to 05555
DRAMs have memories rather like mine-after 2 to 4 milliseconds
go by, they will probably forget unless external circuitry nudges them with
a gentle reminder. This is known as “refreshing” the devices and is a crit-
ical part of every DRAM-based circuit extant.
More and more processors include built-in refresh generators, but
plenty of others still rely on rather complex external circuitry. Any failure
in the refresh system is a disaster.
Any RAM test should pick up a refresh fault-shouldn’t it? After all,
it will surely take a lot longer than 2-4 msec to write out all of the test val-
ues to even a 64k array.
Unfortunately, refresh is basically the process of cycling address
lines to the DRAMs. A completely dead refresh system won’t show up
with the test indicated, since the processor will be memly cycling address
lines like crazy as it writes and reads the devices. There’s no chance the
test will find the problem. This is the worst possible situation: the process
of running the test camouflages the failure!
The solution is simple: After writing to all of memory, just stop tog-
gling those pesky address lines for a while. Run a tight do-nothing loop for
a while (vey tight. . . the more instructions you execute per iteration, the