RAM-Check

Follow this pseudo-code algorithm:

// Checks 99.9% of all RAM failures including all stuck-at-1, stuck-at-0
// problems, full address line check.
//
FOR EACH "Memory Location" DO
Write "Hexadecimals A's" to "Memory Location"
END FOR

FOR EACH "Memory Location" DO
Verify "Hexadecimal A's" at "Memory Location"
Immediately write "Hexadecimal 5's" to "Memory Location"
END FOR

FOR EACH "Memory Location" DO
Verify "Hexadecimal 5's" at "Memory Location"
Immediately write "Hexadecimal A's" to "Memory Location"
END FOR

FOR EACH "Memory Location" DO
Verify "Hexadecimals A's" at "Memory Location"
END FOR

// The only thing I could also suggest adding is a walking-1,
// walking-0 bit check to make sure each data line can be
// independently pulled high or low.

SRAM is a lot easier to test than DRAM. Assuming that you are using SRAM, do the following tests:

1) Checkerboard. Write 0x55 to even locations, 0xAA to odd locations.

2) Inverse checkerboard. Write 0xAA to even locations, 0x55 to odd locations.

3) Address pattern. To each location write:

0xC3 xor (address[23:16]) xor (address [15:8]) xor (address[7:0])

The 0xC3 constant is an arbitrary initial value.


In all tests verify after all locations have been written. The checkerboard tests handle all stuck bit cases and many adjacent cell dependency cases. The address pattern test handles all address line open and short cases.

If you have 16-bit wide RAM, then modify the algorithms accordingly.

You should make sure that timing is correct by design. The only way to test for timing problems is to run continuous RAM tests while varying supply voltage and ambient temperature.

Beware of verification by just writing to a location and then immediately reading it back: this sort of test can pass with the RAM chips not fitted!
(there can be enough capacitance to hold the pattern long enough for the read to "verify" correctly!)

I wrote a ram selftest for c167 which can be run nondestructively. I turn off interrupts, then read the contents of a cell, save it in a register, write the same cell with the 1's complement, read it and compare, then restore it and compare to original contents.

I also do a similar test at address boundaries, that is I shift a bit through the address buss to see if I accidentally change a value. For example, I read and save the contents at 0x40000, then read, save, and replace the value at 0x40002, then look back at 0x40000 to see if it changed, then restore the value at 0x40002. I repeat for all address bits in the ram by shifting the address as 0x40004, 0x40008, etc. If an address bit is stuck I would think this would catch it.

That's right. Maybe I wasn't clear, but I did say verify after all locations have been written. In other words, write the entire RAM, and then verify the entire RAM.

Greg,

Yes, you did!
There was another reply in the thread which didn't seem so clear, but my reply seems to have been attached to your post. Sorry.

Maybe this board just gets a little confused in its threading with different timezones (I'm on GMT in the UK).

Rgds,
Andy.

Back in the old days when DRAM was a new technology, MOSTEK published a test that used an XOR of the address being written, and a counter. You set the counter to 0, and then XOR lsb and msb of address and the counter, then wrote the result to the address. You incremented the address using the same count value and continued until all of ram was filled. You then read it back, generating the compare value with the same algorithm. When this pass was done, you incremented the counter and did the sequence again. This is repeated until the counter cycled to FF.

This method generates a unique, non-repeating pattern in memory, allowing detection of stuck bits, address errors, etc.

Most people don't use this today, as both SRAM and DRAM are much more reliable. However, this test does give a thorough test of the device. It will take a long time to execute though.

Sorry I can't give you the exact algorithm, but I don't have the data book that contained it anymore. It was in the old MOSTEK DRAM data book, circa 1979-1980.

Another good test is an n-squared test, in which each location is accessed from every other location. This gives a thorough test of the device, including its internal hardware for driving address lines.

Try

ftp.embedded.com/.../memtest.zip

Also, I recommend to read article:
Michael Barr, "Software-Based Memory Testing" in EMBEDDED.COM (July 2000)

http://www.embedded.com/code/master.htm

Dear Mr.Michael Barr,

My RAM was showing 384 (128+256) earlier. Now it shows only 382. What went wrong with RAM? How to check that? Could you please help me on this.

Thanks & Regards

G.M.Rao

I will, again, ask WHY?.
The likelyhood of a RAM error in a properly designed system is something like one failure in a million units per year. Note: this excludes "infant mortality"

I just checked with our field service, they have never replaced a SRAM.

Erik

addendum to the above
I just checked with our field service, they have never replaced a SRAM. is correct, there has, of course, been SRAM failures on board that totally failed for reasons like shorted PS etc. Such boards, however waer trashed.

What I refer to above is the SRAM failing on it's own, not due to overvoltage, static or such. In those cases a RAM check would be worthless since the device cheking the RAm is destroyed as well.

Erik

"Dear Mr.Michael Barr"

Why are you addressing Mr Barr? He is not a party to this discussion! His work has simply been referenced!

Have you actually read his paper on memory testing? It explains quite clearly the types of errors that commonly occur in memory systems, and how his tests address them. With that knowledge, you should be able to run the tests and interpret the results.

heiio,
my name is ashish and i what to know the price of every types of ram check.

thank u