0
\$\begingroup\$

I'm currently testing the hardware of a prototype board using DDR2 memory, and I get RAM readback errors when performing a memory test.

The errors happen in this fashion:

# Next iteration
ERR@ 00fd4ad4 got ffda0540 not ffda0560
# Next iteration
ERR@ 00dc9601 got 0042af73 not 0046af73
ERR@ 00f3bec8 got 002f862c not 002f86ac
ERR@ 00fd4ad4 got 0025fa80 not 0025faa0
# Next iteration
# Next iteration
ERR@ 00dc9601 got 0042af74 not 0046af74
ERR@ 00f3bec8 got 002f862d not 002f86ad
ERR@ 00fd4ad4 got 0025fa81 not 0025faa1
# Next iteration
# Next iteration

I have roughly the same thing on 2 boards, and I wonder if it could be a voltage/timing error or if it's definitely a chip issue.

What's your experience on this ?

\$\endgroup\$
2
  • 2
    \$\begingroup\$ Is it always a single-bit error? Do the errors always occur on 0x00040000 or 0x00000020? Does it always occur at specific addresses? Are the same bits corrupted on the other boards? \$\endgroup\$ – W5VO Mar 26 '12 at 15:18
  • \$\begingroup\$ The bit location varied, and not the same bits were corrupted on other boards. Very interesting issue ! \$\endgroup\$ – cJ Zougloub Mar 26 '12 at 17:42
3
\$\begingroup\$

It's almost always the board or timing's fault. RAM is tested at the factory or it is almost never the chip. More likely you have a timing issue; voltage issues would effect more cells.

\$\endgroup\$
1
  • \$\begingroup\$ In my case, it was a timing issue due to a memory controller register not set correctly. The weird thing is that the "undefined behavior" of the misconfiguration was causing the memory to work, but with very bad timings : chilling the chip caused the errors to disappear ! \$\endgroup\$ – cJ Zougloub Mar 26 '12 at 17:40
1
\$\begingroup\$

Many memory test programs are designed to maximize the probability of finding a problem in a certain number of testing steps, and are not at all optimal for diagnosing what the problem might be. A memory test is unlikely to pass unless (1) all write operations to each location store the correct data, (2) all locations continue to hold the last stored data, ignoring reads and writes of other locations, and (3) all read operations read the correct data. Memory tests will detect failures in any of the above steps, but are often not particularly well designed for determining which step failed (If the program stores 0x1234 to 0xABCD but read back 0x89AB, it's possible that address 0xABCD didn't get 0x1234 written to it, or that the correct data was stored to the correct place but subsequently overwritten, or that the correct data was stored--and is still stored--in the correct place, but the read operation doesn't correctly fetch it).

To diagnose a problem given nothing but a list of mismatches between expected and read-back values, one would have to know the sequence of read and write operations used for a test, to see if the mismatch conditions fit any sort of pattern (e.g. if there is a hold time violation on write cycle data, one might notice that the only errors occur when two consecutive write operations are performed and at least some bits are "1" in the first write and "0" in the second; all observed errors bits in the first-written value reading "0" when they should read "1"). Merely knowing an address where a read-back failure was detected, the expected data, and the actual data, won't help much if one doesn't know what other operations were performed at similar addresses.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.