Read Out Initial SRAM Values

Can you share the "value" of such SRAM "dump" - prior to far more normal/customary SRAM initialization?

As launchpad scrimped on Uart level translators - additional code and HW adds to your task.  (and same holds true for most M0 boards we've seen)  Would not your IDE's "view" of SRAM provide greatly "eased" data presentation? 

Further, "internal SRAM of the Stellaris devices is located @ starting address: 0x2000.0000."  Appears you are employing another maker's address scheme...

Andr�� Schaller said:

I want to read out the (possibly random) SRAM values before initialization of SRAM

Perhaps if you explain why you want to do that, it might be easier to make appropriate suggestions as to how to achieve your goal...

http://www.catb.org/~esr/faqs/smart-questions.html#goal

Hi,

A guess would be that you don't have  a space in front of the two "ldr" instructions.  The assembler is therefore likely interpreting them as labels and not instructions. The CCS Assembler User's Guide might be helpful.

Regards,

Sue 

@cb1_mobile: i know that SRAM is located at this address. This was just the beginning of the code used to show an example of the syntax I am using. The board from ST I was using seems to have an identical SRAM address, however the length of their SRAM space is only 0x2000 and the launchpad seems to have 0x8000.

The whole code for the other device can be found here: http://pastebin.com/zKK0fifC. First several configurations are performed regarding the GPIOs and UART configuration (baud rate, number of data bytes, no hardware flow control, etc. pp.) afterwards we iterate over the address space and put every single byte on UART (line 33-39).

@Andy Neil: Sorry I forgot to mention that. My task is to explore the startup values of SRAM of several eval boards to see whether there is any randomness in it. If so, I have to quantify the entropy of the exhibit randomness. If there is no randmoness in it, I have to look for certain patterns in the startup values.

@ Sue Cozart: Thanks for the hint! I was looking for it! My first approach was to simply code the routine in C and keep the assembly, after the code gets compiled. However, I obviously need to work with registers only since I can not touch the RAM. Therefore, I guess I need to build the ASM code manually.

Maybe some ASM friends can help me out with that?

Thanks so far!

Andr�� Schaller said:

The board from ST I was using

Aha! I thought I'd seen this before!

Andr�� Schaller said:

The whole code for the other device can be found here ... we iterate over the address space and

But, surely, apart from parameterising the start & length, that part should be entirely device-independent ?

Andr�� Schaller said:

My task is to explore the startup values of SRAM of several eval boards to see whether there is any randomness in it.

Then I would strongly recommend cb1's suggestion that you use the debugger to just dump the memory.

Putting code into the chip to do this means that you are inherently destroying some of the data you're looking for!!

Andr�� Schaller said:

Maybe some ASM friends can help me out with that?

See above - I don't think that any kind of program on the chip is a good way to achieve your stated aim!

http://en.wikipedia.org/wiki/Observer_effect_(physics)

You may be right regarding the heisenberg argument. However, I got two questions:

1. This observer effect shouldn't occur if my code is loaded in flash memory and the code only uses registers instead of RAM itself, or am I wrong?

2. I am using CCS 5.x for debugging. However, I need to set a breakpoint as early as possible, since just before main() is invoked the RAM will be overwritten with zeros, right? So I am setting a break point just right at the beginning of 

void
ResetISR(void)

in startup_css.c. However, this only works with hardware breakpoints. Plus during the first trial of each debugging process the execution is stopped _after_ this breakpoint (but at the beginning of main()). I need to re-toggle the hw breakpoint and perform a core reset. But at this point in time this doesnt make any sense since the RAM values have already been initialized. I can see this since large areas of 2 memory dumps are totally identical (from 0x20000000-0x20000c80). Obiously I am handling HW breakpoints not appropriate.

Cheers

Andr�� Schaller said:

the heisenberg argument. However, I got two

Rare to see, "Heisenberg" and, "I got" - w/in such proximity.  (although, "Got No xtal ball" has surfaced recently...)

There are multiple, "unknowns" which may contaminate such a measurement - my belief is this scenario is poorly considered.  (and certainly of nominal, "carry forward" value)

As past stated - use of the IDE to view SRAM content seems faster, easier, and less likely to corrupt.  However - even the IDE may contribute to unwanted, "coloring" of results...   

Andr�� Schaller said:

My task is to explore the startup values of SRAM of several eval boards to see whether there is any randomness in it.

Effects like that are quite likely to be affected by things like die's position on the wafer, are likely to vary from batch-to-batch, etc,...

To be meaningful, I think you would have to ensure that you test a representative sample of devices...

Indeed, this is why I have a couple of boards I can test. I have to explore these effects in the context of physically unclonable functions in SRAM. My first approach using ASM code to put all the SRAM bytes on UART before the bss segment got zeroed worked well on the ST boards (even with respect of the observer effect, since the binary was executed from ROM and only used registers and therefore did not touched the SRAM). However, I am struggling to get the ASM code working for the lm4f. And the debugger approach seems to result in biased values.

Andy Neil said:

To be meaningful, would have to ... test a representative sample of devices...

Poster, "This is why I have a couple of boards I can test!"  Aha - surely constitutes hallowed, "representative" sample...

But of course - mon ami - exercise is likely fatally flawed - surely misguided - where is the "oversight?"...

@cb1_mobile: Why so sarcastic? Of course a couple of boards won't satisfy a statistically representative sample of boards. However, the number of trials done with these boards can give a first clue on whats going on. There are published papers accepted at famous conferences with even less boards in context of such experiments. So what?

Sorry, I am not a native english speaker, but I dont't get your second sentence. However, I appreciate your kindness but "mon ami" is bit too much - let's keep it professional :)

Cheers

Of course a couple of boards won't satisfy a statistically representative sample of boards.

I challenge the idea that statistics is involved at all in the RAM power-up content , and zero state is enforced by design. Can you prove me wrong ?

There are only a few results online regarding SRAM startup values of ASCIS. However, there are plenty of results with respect to FPGA SRAM. Most of the devices show a robust PUF behaviour which means that there is up to 20% randomness with a rather high entropy (some results show that we need to extract around 500 Byte to generate 128 bit of full entropy). If you are interested I can point you to some published papers.

Regarding the evaluation board I have examined (STM32F100RB) we see around 77% stable bit (stable = the corresponding bit initialized to either 0 or 1 across all trials) and around 2,5% full-entropy bits (= the overall possibility of the correpsonding bit to intialize to 0 or 1 is 0,5). A statistical behaviour can also be seen as the inter hamming distance (between different boards) which is almost close to an optimal of 0,5 and the intra hamming distance (between different trials of the same board) which is about 0,056. If you are futher interested I can give you detailed experimental results.

However, we have also examined chips that show a stable pattern even across different boards. We are not fully aware of the actual reason but we suspect the internal cicuitry to induce biases between neighboring byte columns / rows.

Regards 

Hi,

If I am allowed, here are a couple of hints working with startup routines and .asm;

• either look at the file StellarisWare/bootloader/bl_startup_ccs.s - it is written entirely in .asm, so you can use breakpoints. Just put the breakpoint on the second or third .asm line, not directly on ResetISR label, since the core pipeline must be filled up to work. 
• either look/search in CCS folder, somewhere there is a /lib/include folder - within this folder there is a single .zip file, containing the source code of all library functions - you will find the source code of _c_int00 module (I am on another OS now, don't remember precisely the location - search for "stdio.h" for instance).
• either modify the ResetISR to avoid that _c_int00 call - an example how to avoid is the file startup_gcc.c. 

Petrei

Hi Petrei,

thanks a lot for those hints! I really appreciate it. I guess they will be helpful. I'll give feedback on my progress.

Best regards