How to check the Heap and Stack RAM consistency on an embedded system

I'm working on a project using a LEON2 Processor (Sparc V8). The processor uses 8Mbytes of RAM that need to be consistency checked during the Self-Test of my Boot. My issue is that my Boot obviously uses a small part of the RAM for its Heap/BSS/Stack which I cannot modify without crashing my application. My RAM test is very simple, write a certain value to all the RAM address then read them back to be sure the RAM chip can be addressed.

This method can be used for most 开发者_StackOverflow社区of the RAM available but how could I safely check for the consistency of the remaining RAM?

Generally a RAM test that needs to test every single byte will be done as one of the first things that happens when the processor starts. Often the only other thing that's done before it is the hardware initialization that needs to happen for the RAM test to be able to access RAM.

It'll usually be done in assembly language with interrupts disabled, for one reason because that's about the only way you can ensure that no RAM is used.

If you want to perform a RAM test after that point, you still need to do it pretty early in the system start-up. You could maybe do it in two passes - where any variables/stack/whatever the test needs for its own purposes are in low RAM, and that test tests high RAM. Then have the test run again with it's data in high RAM while it tests low RAM.

Another note: verifying that you read back a certain value written is a simple test that maybe better than nothing, but it can miss certain types of common failures (common particularly with external RAM: missing or cross soldered address lines.

You can find more detailed information about basic RAM tests here:

• Jack Ganssle, "Testing RAM in Embedded Systems"
• Michael Barr, "Fast Accurate Memory Test Suite"

as I am programming a safety-relevant device, I have to do a full RAM test during operation time. I split the test in two tests:

1. Addressing test

you write unique values to the addresses reached by each addressing line and after all values are written, the values are read back and compared to the expected values. This test detects short-circuits (or stuck@low/high) of addressing lines (meaning you want to write 0x55 on address 0xFF40, but due to a short-circuit the value is stored at 0xFF80, you cannot detect this by test 2:

1. Pattern Test:

You save e.g. the first 4 bytes of RAM in CPU's registers and afterwards you first clear the cells, write 0x55, verify, write 0xAA, verify and restore saved content (you can use other patterns of course) and so on. The reason you have to use the registers is that by using a variable, this variable would be destroyed by that test. You can even test your stack with this test. In our project, we test 4 cells at a time and we have to run this test until whole RAM is tested.

I hope that helped a bit.

If you do your testing before the C run time environment is up you can trash the Heap and BSS areas without any problems.
Generally the stack does not get used much during run time setup so you may be able trash it with no ill effect. Just check your system.
If you need to use the stack during testing or need to preserve it just move it to an already tested area adjust the stack pointer. After wards just restore the old stack and continue.

There is no easy ways of doing this once you entered your runtime environment.