Memory Tests: Firmware Development

[WooDaddy]

Ok..

I got a firmware development question for you ATers. I'm developing a firmware-level memory test and need to make sure that it's actually testing (not stressing) my devices correctly. An existing test basically inserted 0xA5A5A5A5 into registers and memory locations and checked that it was written correctly. This obviously does nothing. I'm suggesting performing 0xAAAAAAAA and 0x55555555 or walking 1's and 0's. This will help verify the cells in the memory devices and potential data line solder shorts. Are there any other methods that you can suggest that can also verify address line problems? What's a better test vector?

I'm more concerned with physical device problems than data throughput.

 

[blahblah99]

It'll take a while, but writing 0s, verifying, writing 1s, and verifying guarantees that each bit in the memory can be set to 0 and 1.

Provided, of course, that the device accessing the memory doesn't require any program data to reside in that memory.

 

[BEL6772]

To catch address errors, you need some kind of a linked test. For example, you could establish a background (0s, 1s or checkerboard ... doesn't matter), verify <address> and <address + 1>, change <address> to its compliment, re-check both, increment the address and repeat through the array.

 

[Peter]

You'll find that running a useful RAM test and booting the system in a bearable time frame are mutually exclusive. Proper RAM test on half a gigabyte of RAM or more takes minutes to hours.

www.memtest.org

Use the source, Luke!

 

[shekondar]

I did this for a project a while back - there are three sets of tests that you should run - the data bus, the address bus, and the actual memory device. For the data and address bus tests, you can do a "walking ones" test - this tests each bit of the bus individually. It is not necessary to test every possible address. The device test takes the longest, since you have to write to and read from each memory location twice (use any value for the first write, invert it for the second write).

This site explains the different tests and has some sample code:
text

Like blahblah99 said, you need to make sure you don't have anything important in memory before testing it - these tests are destructive (unless you copy the data out of the memory locations you are going to test, then replace it when you are finished).

 

[WooDaddy]

Actually, I should restate my last statement. I'm more concern with manufacturing defects (solder shorts, lifted pads, etc) than device problems. In order of priority:
1 - data
1 - addr
3 - cell fault (device test)

BEL6772,
Thanks. My co-worker gave me the same advice to use that tagged address test. That's the last frontier for me since I'm sure that walking ones verifies the data lines and individual cells of my memory devices.

Peter,
I'm not doing that much of ram. Also, this is for embedded system not a standard PC though. It's actually more complex but nevertheless, thanks for the link. I'm sure I can get some good info out of the source code.

Shekondar,
that's actually what's being done (sorta) now. I'll have to do some yield analysis to see if I really need to do a full device test because of test time constraints. That ESA website is great. I'm bookmarking that bad boy.

You should be able to tell by now I'm a test development engineer by trade.

I REALLY appreciate your help. I'll try not to abuse it.

Edit: Just to add.. I'm a complete numnutz. I have Michael Barrs' book and completely forgot about it. That's where the memory test article at ESA came from.. DUH!!

 

[harrkev]

Here is how I would handle it.... Pseudo-random patterns. Fill your entire free memory with a pseudo-random pattern using a known seed. Then, read it all back! Repeat a few different times using different known seeds. I would do this in addition to the usual fill with ones and zeros.

Filling with ones and zeros is good for detecting stuck bits, but that's about it. Even the "A's and 5's" test can miss things like having address lines shorted together. But doing a "ones and zeros" test and then two pseudo-random patterns can catch any error that I can think of.