Michael Barr wrote a great article a few years ago about RAM tests. A simple $55/$AA test like what you describe actually isn't very effective at finding typical memory failures. I highly recommend the article! http://www.embedded.com/2000/0007/0007feat1.htm (If you're writing the RAM test for manufacturing, the article will tell you how to make your test much more effective. We're getting great results with Mr. Barr's techniques here. If you're writing the RAM test for school, putting a bit of what you learn from this article into your writeup will dazzle your professor, which is always a good move! :-) On Mon, Mar 21, 2005 at 03:11:23AM +0000, the_oog6789 wrote: > When i start writing directly to ram (using asembler) I can only get > from 0x2000 to 0x2010, any further than that and the program will > hang. The number of variables I have exceeds 10 bytes so I > shouldn't be writing over anything but those first few. I'm not sure I follow the last sentence there. Do you *know* you're overwriting the program's variables? Since I'm not sure I follow you, here is some general advice: When writing RAM tests, I always find it surprisingly easy to accidentally "test" the RAM where my program lives. The result is a crash as the program destroys itself. See if you can get a map file from your compiler, and match it up with the memory map from the monitor program you're using. The union of the two is the areas you must avoid. If you have the COP enabled, make sure your program tickles it every now and then during the RAM test so the CPU isn't reset. Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center |