Forums

state of PIC SRAM on boot

Started by kyle york May 11, 2007
Greetings,

What is the state of the PIC SRAM on power up? Random value, determined 
value, last set value? Long ago I thought I'd read that unlike DRAM, 
SRAM maintains its values on power down, but I cannot find a reference 
to that at the moment.

-- 
Kyle A. York
Sr. Subordinate Grunt
kyle york wrote:
> Greetings, > > What is the state of the PIC SRAM on power up? Random value, determined > value, last set value? Long ago I thought I'd read that unlike DRAM, > SRAM maintains its values on power down, but I cannot find a reference > to that at the moment. >
This is totally wrong. These is _no_ RAM of any kind that will maintain its values on power down. ROM yes, RAM no. So, you did not read this anywhere. Some RAM chips may power up in the same state as the last time it was powered up, but it is not guaranteed. donald
On May 11, 11:28 am, Donald <Don...@dontdoithere.com> wrote:

> This is totally wrong. > > These is _no_ RAM of any kind that will maintain its values on power down.
This is totally wrong. FRAM, and core - for similar reasons - maintain their values on power down.
On Fri, 11 May 2007 08:19:18 -0700, the renowned kyle york
<kyork@cisco.com> wrote:

>Greetings, > >What is the state of the PIC SRAM on power up? Random value, determined >value, last set value? Long ago I thought I'd read that unlike DRAM, >SRAM maintains its values on power down, but I cannot find a reference >to that at the moment.
It's not guaranteed to be anything in particular. Chances are it's far from random, and if the power down was brief, or incomplete, probably influenced to a certain extent by the previous states. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
larwe wrote:
> On May 11, 11:28 am, Donald <Don...@dontdoithere.com> wrote: > > >>This is totally wrong. >> >>These is _no_ RAM of any kind that will maintain its values on power down. > > > This is totally wrong. FRAM, and core - for similar reasons - maintain > their values on power down. >
FRAM != RAM
On May 11, 12:44 pm, Donald <Don...@dontdoithere.com> wrote:

> FRAM != RAM
Guess what: <http://www.ramtron.com/doc/AboutFRAM/Default.asp> "FRAM offers features consistent with a RAM technology, but is nonvolatile like a ROM technology. FRAM bridges the gap between the two categories and creates something completely new -- a nonvolatile RAM." Parallel FRAM looks pretty much exactly like SRAM from the system's perspective; it is a drop-in replacement. e.g. <http://www.ramtron.com/ doc/Products/Nonvolatile/Detail.asp?ID=12&gr=6> is a direct drop-in for a 62256 32Kx8 SRAM. Not that the OP isn't on crack, of course, but your statement isn't absolutely right, which is why it irked me to see it advertised as such.
larwe wrote:
> On May 11, 12:44 pm, Donald <Don...@dontdoithere.com> wrote: >>FRAM != RAM > Guess what: <http://www.ramtron.com/doc/AboutFRAM/Default.asp> > > "FRAM offers features consistent with a RAM technology, but is > nonvolatile like a ROM technology. FRAM bridges the gap between the > two categories and creates something completely new -- a nonvolatile > RAM." > > Parallel FRAM looks pretty much exactly like SRAM from the system's > perspective; it is a drop-in replacement. e.g. <http://www.ramtron.com/ > doc/Products/Nonvolatile/Detail.asp?ID=12&gr=6> is a direct drop-in > for a 62256 32Kx8 SRAM. > > Not that the OP isn't on crack, of course, but your statement isn't > absolutely right, which is why it irked me to see it advertised as > such.
and to confuse you all even more, have a look a Maxims high security "Low imprinting" SRAM technology. Yes, seems SRAM is not truly random on power off, but does have a statistical bias based on what was there last time.... Not good enough to get 100% data back, but I'm sure cracking teams would love to have a 'better seed' than a random starting point. Not likely to matter much, in the average PIC project :) -jg
Greetings,

Jim Granville wrote:
> Yes, seems SRAM is not truly random on power off, but does have > a statistical bias based on what was there last time.... > Not good enough to get 100% data back, but I'm sure cracking teams > would love to have a 'better seed' than a random starting point. > > Not likely to matter much, in the average PIC project :)
Thanks for straightening me out everyone. I was hoping it would be either maintained or in a somewhat random state so I could use it as a seed to a PRNG. -- Kyle A. York Sr. Subordinate Grunt
kyle york wrote:
> Greetings, > > Jim Granville wrote: >> Yes, seems SRAM is not truly random on power off, but does have >> a statistical bias based on what was there last time.... >> Not good enough to get 100% data back, but I'm sure cracking teams >> would love to have a 'better seed' than a random starting point. >> >> Not likely to matter much, in the average PIC project :) > > Thanks for straightening me out everyone. I was hoping it would be > either maintained or in a somewhat random state so I could use it as a > seed to a PRNG. >
If you need to store something many PICs have built in EEPROM or Self programable Flash
On 2007-05-11, kyle york <kyork@cisco.com> wrote:
> > Thanks for straightening me out everyone. I was hoping it would be > either maintained or in a somewhat random state so I could use it as a > seed to a PRNG.
There are ways to take semi-random data and create random data from it using some kind of hash. Proably the simplest is applying an XOR function something along the lines of: int gen_seed(int array[], unsigned length) { int value = array[0]; while(--length) value ^= array[length]; return value; } Provided that length is large enough, any underlying tendencies of memory bits to favour one value or the other are soon swamped by the randomness present in other bits. I have a mathematical analysis of the above code somewhere that states how long length must be to create a truly random number, based on how strong the tendencies are. I'll have a look around and see if I can dig it up. Of course, hardware random number generation needn't be particularly complex: see http://willware.net/hw-rng.html for an example. -- Andrew Smallshaw andrews@sdf.lonestar.org