RAM-Check

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details	Message
Read-Only Author HP Ihringer Posted 23-Nov-2000 13:59 GMT Toolset C166	RAM-Check HP Ihringer Hello, I am looking for a sophisticated RAM-Check-algorithm, that does not only detect problems with one cell like a simple write and read back. It should also be able to detect short ciruits and breaks of address-lines and maybe timing problems on the address-bus. Thanks!

Read-Only Author Ted Dubroff Posted 23-Nov-2000 16:28 GMT Toolset C166	RE: RAM-Check Ted Dubroff 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.

Read-Only Author Greg Neff Posted 23-Nov-2000 17:30 GMT Toolset C166	RE: RAM-Check Greg Neff 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.

Read-Only Author Andrew Neil Posted 24-Nov-2000 09:21 GMT Toolset C166	RE: RAM-Check Andrew Neil 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!)

Read-Only Author Greg Neff Posted 24-Nov-2000 17:40 GMT Toolset C166	RE: RAM-Check Greg Neff 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.

Read-Only Author Andrew Neil Posted 27-Nov-2000 12:20 GMT Toolset C166	RE: RAM-Check Andrew Neil 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.

Read-Only Author Ashish` Kumar Posted 17-Jul-2006 09:50 GMT Toolset C166	RE: RAM-Check Ashish` Kumar heiio, my name is ashish and i what to know the price of every types of ram check. thank u

Read-Only Author Doug Moore Posted 24-Nov-2000 14:36 GMT Toolset C166	RE: RAM-Check Doug Moore 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.

Read-Only Author tom mazowiesky Posted 27-Nov-2000 14:42 GMT Toolset C166	RE: RAM-Check tom mazowiesky 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.

Read-Only Author Sergey Posted 28-Nov-2000 09:07 GMT Toolset C166	All you need is Michael Barr's "memtest" Sergey Try ftp://ftp.embedded.com/pub/2000/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

Read-Only Author Markandeswara Rao Gunnu Posted 10-Oct-2005 02:03 GMT Toolset None	RE: All you need is Michael Barr's "memtest" Markandeswara Rao Gunnu 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

Read-Only Author erik malund Posted 10-Oct-2005 13:35 GMT Toolset None	RE: All you need is Michael Barr's "memtest" erik malund 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

Read-Only Author erik malund Posted 10-Oct-2005 13:38 GMT Toolset None	RE: All you need is Michael Barr's "memtest" erik malund 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

Read-Only Author A.W. Neil Posted 10-Oct-2005 20:03 GMT Toolset None	RE: All you need is Michael Barr's "memtest" A.W. Neil "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.

Next Thread | Thread List | Previous Thread Start a Thread | Settings