Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How would I write to memory?

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

Essentially write out certain patterns: "10101010101010" to a block of memory then write "01010101010" then re-write the first one and test to see if the pattern was written correctly.

I am trying to write this program in C. I was wondering how I would go about writing this pattern. I want to be able to flip certain bits within the RAM memory cells on and off.

Would I just get allocate a block of memory and then write do 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

Would the code above work?? Will writing out the hex patterns to memory turn the bits on in the pattern?

I know the code above is horribly mangled but I just want to get an idea if doing something like that with the correct logic will achieve the desired result.

Thanks

like image 840
Falcata Avatar asked Dec 31 '25 22:12

Falcata


1 Answers

You have a chicken and egg problem. In order to get enough code running to do mallocs or even use C code, you already have working memory.

You need to define your problem. For example is this design verification or production testing? Are you testing the memory chip itself or the board. Normally you will buy working/tested chips (memory) or memory chips that have some vendor defined quality. And your testing is often production testing, the manufacturing solder points. The data lines, the address lines, the control lines.

The chicken and egg problem is you want to run software on the embedded processor which requires code that runs somewhere, and that implies memory (could just be flash and not need any or minimal). the ideal situation is to either run completely out of rom, using processor resources only or internal chip resources only and no exteral ram so the external ram can be completely tested. Every address line, etc. Otherwise you need to come up with a scheme or declare chunks of memory to not be tested.

Or take a multi stage approach, the rom boot code can do a quick check of a small part of ram without using it to run. Then copy the main test program to that small chunk of ram and run within it. Then do the main memory tests with more code flexibility. Can use C instead of assembler for example. You might for example pre-test, super simple test, 25% of the ram, then copy the test there, test the other 75%, then move the program to another 25% in the ram space and do the heavy test on the first 25% that didnt get a full test.

Types of test, you need to understand the failures, you may want to test solder joints in particular and pcboard traces. So you can have open connections so you want to make each pin a one and a zero, also you can have shorts, which the one and zero covers, and you might have "friendly bits" where neighboring pins might have a short to each other so you want to have each pair of signals be different from each other.

Often folks will do tests like all ones, all zeros, 5s, As. Then checkerboard tests where one memory location has say 5s and the next has As. for address line testing you need to use non-powers of two, or even better every memory location in memory has a different value, for example 32 bit words each getting their own address.

As a quick test I cover most of that in a couple of tests, if you use a pseudo randomizer, something repeatable like an lfsr, one pass to fill all of memory using the randomizer, re-seed, go back through and check. then go through again and fill with inverted values, re-seed and verify inverted values. you get address bits, each data line but not all neighbors are checked. re-seeding and starting all of this over moving the random pattern around can cover that. sometimes just using the random test as the address test and the traditional ones zeros fives As, 3s, Cs, 6s, 9s, etc.

as far as your pointer to memory under test you dont just malloc you need to know the physical address and deal with the translation if any so that if/when there is a problem you are communicating in physical addresses. Also you know and control how much of the memory. Normally I will write processor based tests in C, but wont use any C library calls (like malloc or printf or anything like that).

like image 61
old_timer Avatar answered Jan 02 '26 12:01

old_timer



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!