CODEWITHSUNDEEP
ctestingembeddedram
nodee3345
nodee3345

Reputation: 19

How to stop RAM test destroying its own variables embedded C?

During startup tests I am required to test all RAM locations using a galpat test, I have wrote the function to do this but run into a problem that the functions variables exist in RAM and therefore get mashed as part of the test.

What would be the best way around this?

Upvotes: 1

Views: 695

Answers (4)

rjp
rjp

Reputation: 1820

If you do have ROM space and can afford the time at boot time, I would implement the test in assembly or in a naked C function using directives to put your variables in registers so that no RAM is consumed as part of the test. This is going to be pretty architecture and compiler specific, though, and neither of those were mentioned.

Upvotes: 0

Gabriel Cséfalvay
Gabriel Cséfalvay

Reputation: 539

My approach would be this:

  1. Do the test before anything is initialized (variables, stack). In gcc you can: void RAM_test(void) _attribute_ ((section (".init0")));

  2. Write it in assembly. Ensure that the test does not use/store any variables in the RAM, only uses processor registers.

  3. Store the result somewhere so you can use it later in normal program.

Upvotes: 0

tofro
tofro

Reputation: 6063

A possible approach could be - especially taking care of the processor stack, .data and .bss is something you can avoid - but there is no easy way to have C work without a proper stack:

  • Write your code that it exclusively uses ROM code and stack variables.
  • Have your startup code (that would normally be written in assembler anyhow) allocate the stack in the upper half of memory, test the lower half
  • move (copy) the stack from upper memory to already tested areas (can be done in C)
  • Reset the stack pointer to point to the copied stack (involves assembler coding)
  • Do the rest of the memtest (can be done in C again)

(This assumes your code runs from ROM, which it would normally do at such early point in the start-up). In case there is any memory failure in areas where you allocate the stack, your code will simply crash (What it does before that - Reactor meltdown... - depends on the application).

When moving the stack around outside C's control, you should be very careful what you actually store there - Pointers to stack variables will become invalid - or rather undefined - once you've moved the stack. Simple scalar variables and pointers to outside the stack as typically used in a RAM test should work, however.

You could try and declare your variables as register to try and keep RAM usage as low as possible - But you can't force C to put certain variables into registers, and a good C compiler will put them there anyhow.

Whether this is any better than writing the whole memtest in assembler (you'd need to do the stack adjustments in assembler anyhow, as there is no means to move the processor stack around in C) I dare to challenge. I don't see much of a point here using C on this low level, especially as assembler could run a memtest routine completely from registers, without using any RAM. This makes it much more immune to any RAM problem. A RAM testing routine shouldn't rely on working memory.

Upvotes: 1

old_timer
old_timer

Reputation: 71536

The bottom line is you cannot, you have two choices, you can either only test part of the ram or part of the ram at a time which means you are not doing a complete address test. Or you dont run from the ram you are testing, which is basically the rule if you really want to test the ram. So you have to run from rom with out using a stack in the ram under test or you use another ram, perhaps there is a cache somewhere that can be used direct access to give you a little ram.

Testing half or some other fraction at a time, which is not a complete test, but better than not testing part of it at all, can be done with either a position independent module or with multiple compiles of the test that are position dependent. No reason for the stack to be an issue, the rom based code copying and jumping to the code under test can set the stack pointer based on the fraction under test or not under test, and then repeat. Treat the module like a function not like an entire program and the preserving the stack or "moving the test" problem goes away it returns back to the rom based code which can relaunch further tests.

One crazy way to do it would be to attempt to turn on the I cache get the test code into the cache (before it hits itself), and then blast away at the ram including the code behind the ram. (cant have stack) I would only try this as a fun experiment but not for anything real. Lots of problems to solve with an approach like this.

Upvotes: 0

Related Questions