Running code out of RAM

On Mon, 24 May 2004 22:49:21 GMT, Darin Johnson <darin_@_usa_._net>
wrote in comp.arch.embedded:

> 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).

But none of these features provides any protection against soft errors
or actual RAM hardware errors.  With any type of DRAM, in particular,
it pays to be careful.

-- 
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 <Haran.Vela@ieee.org> says...

>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?

Very reliable.  

On Mon, 24 May 2004 20:56:43 -0400, "Haran Vela" <Haran.Vela@ieee.org>
wrote:

>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?

Unless the device is working in some extreme conditions, RAM
reliability would never be an issue. You're more likely to have a
dicky power supply or ill-designed power-down circuitry.

Ken.

>
>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/
>>
>
>


+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

"Ken Lee" <postmaster@noname.com> wrote in message
news:40b2b9a4.691371968@news.individual.net...
> On Mon, 24 May 2004 20:56:43 -0400, "Haran Vela" <Haran.Vela@ieee.org>
> wrote:
>
> >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?
>
> Unless the device is working in some extreme conditions, RAM
> reliability would never be an issue. You're more likely to have a
> dicky power supply or ill-designed power-down circuitry.
>
Interesting that you should say this as I've had three pieces of "consumer
kit" (firewall, router, external disc drive) all fail because of power
supply circuit problems recently. I suspect that the power supply tends to
get forgotten in a lot of designs (reference designs from which they are
derived tending to be "the logic" and the power supply an afterthought).

    Andrew

Andrew Jackson <alj@nospam.com> says...

>Interesting that you should say this as I've had three pieces of "consumer
>kit" (firewall, router, external disc drive) all fail because of power
>supply circuit problems recently. I suspect that the power supply tends to
>get forgotten in a lot of designs (reference designs from which they are
>derived tending to be "the logic" and the power supply an afterthought).

These people make good power supplies:
http://www.pcpowerandcooling.com/home.htm


-- 
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/ 

On Mon, 24 May 2004 20:59:37 -0500, Jack Klein <jackklein@spamcop.net>
wrote:

>On Mon, 24 May 2004 22:49:21 GMT, Darin Johnson <darin_@_usa_._net>
>wrote in comp.arch.embedded:
>
>> 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).
>
>But none of these features provides any protection against soft errors
>or actual RAM hardware errors.  With any type of DRAM, in particular,
>it pays to be careful.

Since the original code is in (((E)E)P)ROM, why not just copy it from
ROM to RAM at frequent intervals ? Some simple memory word parity
could be used to trigger the copying operation in addition to the
periodic copying. Frequent copying (in order to avoid more than one
SEU in a memory word) should not be a problem compared to RAM CRC
calculations, unless the RAM:ROM speed ratio is larger than 10:1. 

If you do not have a reliable code backup copy in the system, then
using ECC RAM and frequently reading and writing back (with corrected
memory words and ECC bits) every memory word should largely prevent
the formation of two or more bit errors in the same word, which would
not be correctable.

Paul

Thank you all for some very useful suggestions. I feel a lot more
comfortable now and have some strategies to pursue.

Thanks.
Haran.

"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?
>
> Thanks.
>
>

Andrew Jackson <alj@nospam.com> says...

>Interesting that you should say this as I've had three pieces of "consumer
>kit" (firewall, router, external disc drive) all fail because of power
>supply circuit problems recently. I suspect that the power supply tends to
>get forgotten in a lot of designs (reference designs from which they are
>derived tending to be "the logic" and the power supply an afterthought).

These people make good power supplies:
http://www.pcpowerandcooling.com/home.htm


-- 
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/