How will I write to memory?

I am trying to write a simple RAM test to check the basic memory integrity on an embedded device. This is what I want to do:

Essentially write out certain patterns: "10101010101010" into the memory block, then write "01010101010", then overwrite the first one and check if the pattern is written correctly.

I am trying to write this program in C. I was wondering how I would write this circuit. I want to turn certain bits on and off in RAM locations.

I would just allocate a block of memory and then write something like

uint32 pattern = 0xaaaaaaaa;
uint32 * mem_loc = malloc some memory;
int i = 0;
int offset = 1; 
uint32 * location = &mem_loc;

while ((&mem_loc)++ && (!i))  {
   &mem_loc = pattern;
   if (!(&(mem_loc+offet))) { 
      mem_loc = location;
      pattern = 0x55555555;
      i++;
   }
}

//Check to see if values written are consistent

      

Does the code above work? After doing hex patterns in memory, include the bits in the pattern?

I know the code above is horribly garbled, but I just want to get an idea if something like this with the correct logic achieves the desired result.

thank

+3


source to share


3 answers


You have a chicken and egg problem. To get enough code to work with mallocs or even using C code, you already have working memory.

You need to identify your problem. For example, is this design review or product testing? You are testing a memory chip or board. Usually you buy working / tested chips (memory) or memory chips that are of a certain quality as specified by the supplier. And your tests are often production tests, production soldering points. Data lines, address lines, control lines.

The problem with chicken and egg is that you want to run software on an embedded processor that requires code that runs somewhere and that implies memory (maybe just flash and doesn't need any or minimal). the ideal situation is to either run entirely from the novel, using only the processor's resources, or only the internal resources of the chip, and no exterritorial bar, so that the external pin can be fully tested. Each line of address, etc. Otherwise, you need to come up with a schema or declare chunks of memory so that they are not tested.

Or take a multi-step approach, the boot rom can quickly check a small part of the bar without using it to run. Then copy the main test program to this small chunk of ram and run it. Then run basic memory tests with more code flexibility. For example, you can use C instead of assembler. You could, for example, do a pre-test, a super-simple test, 25% of the bar, then copy the test there, check the remaining 75%, then move the program another 25% into the exit space, and do a hard test on the first 25% that is not passed the full test.



The types of tests you need to understand the faults, you can test the solder joints, in particular, and the pcboard marks. This way you can have open connections, so you want each pin to be one and equal to zero, also you can have shorts that cover one and zero, and you can have "friendly bits" where adjacent pins can have short to each other so you want each pair of signals to be different from each other.

Often people will do tests like everyone else, all zeros, 5s, As. Then tests on a chessboard, where one memory cell has 5 seconds and the next one has As. to test the address bar, you need to use the non-permissions of two or even better so that each memory location in memory has a different meaning, like 32-bit words, each getting its own address.

As a quick test, I cover most of them in a few tests, if you are using a pseudo randomizer, something repeatable like lfsr, one pass to fill all memory using a randomizer, re-seed, go back and check. then run again and fill in the inverted values, reseed and check the inverted values. you get address bits, every row of data is checked, but not all neighbors. re-seeding and starting it all while moving a random pattern around can cover it up. sometimes just using a random test as an address test, and the traditional ones are the zeros of the five As, 3s, Cs, 6s, 9s, etc.

as far as your pointer to the memory being tested you are not just malloc, you need to know the physical address and deal with the translation, if so, if, with / without a problem, you communicate at physical addresses. You also know and control the amount of memory. I will usually write processor based tests in C, but will not use any calls to the C library (like malloc or printf or anything like that).

+3


source


Echoing @ Martin's answer: you don't want to use standard library calls to provide memory checking.

Your built-in toolchain should be able to create a memory map of your application. You need to identify the memory segments you want to test and extract their starting address from the map file.

The test loop might look something like this:



 const int* AddressToTest = MEM_SEGMENT;
 const int* SegLength     = SEGMENT_LENGTH;
 volatile int* mem;
 for (mem = AddressToTest; mem < AddressToTest + SegLength; mem++)
 {
    *mem = PATTERN;
    if (*mem != PATTERN) {report("Read-Write Failure at %x",mem);}
 }
 //-or- you could separate the write and verify into 2 separate loops.

      

The big problem is that you cannot test the segment you are working from, so you need to plan it carefully. Nested tools must have some sort of linker options file (and / or complier #pragmas) that determine which code is using that memory. Thus, you need to set up your test code to run in a separate location than the memory under test.

+2


source


Do you want to use new

?
If you're trying to test certain areas of the on-board system memory, wouldn't you want to set that address directly rather than relying on what new

gives you?

If this embedded system is indeed Linux or Windows, embedded or some other complex OS, then it is perhaps more complex, you may have memory address spaces for different processes, caches and optimistic allocations.

0


source







All Articles