Forums

Running code out of RAM

Started by Haran Vela May 23, 2004
We are in the process of writing code to execut out of SDRAM for the first
time in an upcoming project. Until now all our systems executed code out of
eprom or flash. However we need the speed that comes with running out of
SDRAM but are concerned about SDRAM reliability issues and the possbility of
rouge pointers corrupting SDRAM. Any RAM corruption will cause down time and
reliability issues in our systems but will not kill anybody. Has this been a
concern for anybody and if so how have you handled it?

Thanks.


In article <HIydnZ31VN9s_CzdRVn-vg@comcast.com>, Haran Vela wrote:

> We are in the process of writing code to execut out of SDRAM > for the first time in an upcoming project. Until now all our > systems executed code out of eprom or flash. However we need > the speed that comes with running out of SDRAM but are > concerned about SDRAM reliability issues and the possbility of > rouge pointers corrupting SDRAM.
Even if you're code is in ROM, I presume you're used to have data and stack in RAM, right?
> Any RAM corruption will cause down time and reliability issues > in our systems
Just as it would have with code in ROM.
> but will not kill anybody. Has this been a concern for anybody > and if so how have you handled it?
Same as with code in ROM: pay attention to what you're doing during design and coding -- then test your software. -- Grant Edwards grante Yow! How many retired at bricklayers from FLORIDA visi.com are out purchasing PENCIL SHARPENERS right NOW??
On Sun, 23 May 2004 22:46:09 -0400, "Haran Vela" <Haran.Vela@ieee.org>
wrote in comp.arch.embedded:

> We are in the process of writing code to execut out of SDRAM for the first > time in an upcoming project. Until now all our systems executed code out of > eprom or flash. However we need the speed that comes with running out of > SDRAM but are concerned about SDRAM reliability issues and the possbility of > rouge pointers corrupting SDRAM. Any RAM corruption will cause down time and > reliability issues in our systems but will not kill anybody. Has this been a > concern for anybody and if so how have you handled it? > > Thanks. >
In addition to what Grant said, you can (and probably should) test your image in RAM. Use your development tools to separate writeable sections (initialized variable data, stack space, uninitialized data, etc.) from non-writable sections (code, constant data), that is the ones that are still in EPROM or flash right now. At system start up, when your initialization code copies the code and constant sections from original storage to SDRAM, compute some soft of checksum or CRC on the image. Then have a background task periodically repeat this calculation. If the background task finds that the image area has been changed, it should lock the system in some sort of fail safe condition and indicate the reason. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Haran Vela wrote:
> We are in the process of writing code to execut out of SDRAM for the first > time in an upcoming project. Until now all our systems executed code out of > eprom or flash. However we need the speed that comes with running out of > SDRAM but are concerned about SDRAM reliability issues and the possbility of > rouge pointers corrupting SDRAM. Any RAM corruption will cause down time and > reliability issues in our systems but will not kill anybody. Has this been a > concern for anybody and if so how have you handled it?
Broken code is broken code, whereever it runs. Buffers should always be checked for overruns. If you are concerned, I think a code review is in order.
Haran Vela <Haran.Vela@ieee.org> says...

>We are in the process of writing code to execut out of SDRAM for the first >time in an upcoming project. Until now all our systems executed code out of >eprom or flash. However we need the speed that comes with running out of >SDRAM but are concerned about SDRAM reliability issues and the possbility of >rouge pointers corrupting SDRAM. Any RAM corruption will cause down time and >reliability issues in our systems but will not kill anybody. Has this been a >concern for anybody and if so how have you handled it?
Are you worried about the actual reliability of RAM vs. ROM or do you suspect that you have buggy code that is rying to overwrite program memory and failing because it it read-only? -- Guy Macon, Electronics Engineer & Project Manager for hire. Remember Doc Brown from the _Back to the Future_ movies? Do you have an "impossible" engineering project that only someone like Doc Brown can solve? My resume is at http://www.guymacon.com/
"Haran Vela" <Haran.Vela@ieee.org> wrote in message
news:HIydnZ31VN9s_CzdRVn-vg@comcast.com...
> We are in the process of writing code to execut out of SDRAM for the first > time in an upcoming project. Until now all our systems executed code out
of
> eprom or flash. However we need the speed that comes with running out of > SDRAM but are concerned about SDRAM reliability issues and the possbility
of
> rouge pointers corrupting SDRAM. Any RAM corruption will cause down time
and
> reliability issues in our systems but will not kill anybody. Has this been
a
> concern for anybody and if so how have you handled it? >
Assuming your code is in one contiguous block of RAM, then if you are really paranoid, you can make a debug board that monitors the address bus / write line and generates an external interrupt on any attempt to write to the code area. Tanya
Haran Vela wrote:
> > We are in the process of writing code to execut out of SDRAM for > the first time in an upcoming project. Until now all our systems > executed code out of eprom or flash. However we need the speed > that comes with running out of SDRAM but are concerned about > SDRAM reliability issues and the possbility of rouge pointers > corrupting SDRAM. Any RAM corruption will cause down time and > reliability issues in our systems but will not kill anybody. Has > this been a concern for anybody and if so how have you handled it?
The rouge problem is cured by forbidding makeup to the sisters :-) After that, write correct code. About the only thing that can harm is cosmic rays, and you can detect most of those (very rare) events with CRC checksums over the load module, or with ECC memory. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
In article <40B1BEDE.38524DCF@yahoo.com>, cbfalconer@yahoo.com says...
> Haran Vela wrote: > > > > We are in the process of writing code to execut out of SDRAM for > > the first time in an upcoming project. Until now all our systems > > executed code out of eprom or flash. However we need the speed > > that comes with running out of SDRAM but are concerned about > > SDRAM reliability issues and the possbility of rouge pointers > > corrupting SDRAM. Any RAM corruption will cause down time and > > reliability issues in our systems but will not kill anybody. Has > > this been a concern for anybody and if so how have you handled it? > > The rouge problem is cured by forbidding makeup to the sisters > :-) After that, write correct code. About the only thing that > can harm is cosmic rays, and you can detect most of those (very > rare) events with CRC checksums over the load module, or with ECC > memory. > >
-- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Obviously, Mr. Falconer is not a Jeopardy Fan! ;-) Mark Borgerson
Jack Klein <jackklein@spamcop.net> writes:

> At system start up, when your initialization code copies the code and > constant sections from original storage to SDRAM, compute some soft of > checksum or CRC on the image. Then have a background task > periodically repeat this calculation.
Some CPUs have memory protection hardware, so that you can make sections of memory read-only. If this capability exists it's well worth using it; and you can catch hardware exceptions when these illegal writes occur in order to detect the culprits. There are also poor man's memory protection methods as well, where write enable lines to the RAM pass through a GPIO gateway (with some address logic as well). -- Darin Johnson "Look here. There's a crop circle in my ficus!" -- The Tick
Actually both. As most of the postings have indicated, buggy code has to be
dealt with through better development and testing processes but what are
your views on RAM reliability?

Thanks


"Guy Macon" <http://www.guymacon.com> wrote in message
news:Erydne0PVc7CDCzdRVn-vA@speakeasy.net...
> Haran Vela <Haran.Vela@ieee.org> says... > > >We are in the process of writing code to execut out of SDRAM for the
first
> >time in an upcoming project. Until now all our systems executed code out
of
> >eprom or flash. However we need the speed that comes with running out of > >SDRAM but are concerned about SDRAM reliability issues and the possbility
of
> >rouge pointers corrupting SDRAM. Any RAM corruption will cause down time
and
> >reliability issues in our systems but will not kill anybody. Has this
been a
> >concern for anybody and if so how have you handled it? > > Are you worried about the actual reliability of RAM vs. ROM or do > you suspect that you have buggy code that is rying to overwrite > program memory and failing because it it read-only? > > > -- > Guy Macon, Electronics Engineer & Project Manager for hire. > Remember Doc Brown from the _Back to the Future_ movies? Do you > have an "impossible" engineering project that only someone like > Doc Brown can solve? My resume is at http://www.guymacon.com/ >