Running code out of RAM

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.

Reply to
Haran Vela
Loading thread data ...

Even if you're code is in ROM, I presume you're used to have data and stack in RAM, right?

Just as it would have with code in ROM.

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
 Click to see the full signature
Reply to
Grant Edwards

On Sun, 23 May 2004 22:46:09 -0400, "Haran Vela" wrote in comp.arch.embedded:

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
 Click to see the full signature
Reply to
Jack Klein

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.

Reply to
Jim Stewart

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 
 Click to see the full signature
Reply to
Guy Macon

of

of

and

a

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

Reply to
tanya

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?
 Click to see the full signature
Reply to
CBFalconer

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Mark Borgerson

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
Reply to
Darin Johnson

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

first

of

of

and

been a

Reply to
Haran Vela

On Mon, 24 May 2004 22:49:21 GMT, Darin Johnson wrote in comp.arch.embedded:

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
 Click to see the full signature
Reply to
Jack Klein

Very reliable.

Reply to
Guy Macon

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.

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

be

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

Reply to
Andrew Jackson

These people make good power supplies:

formatting link

--
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
 Click to see the full signature
Reply to
Guy Macon

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

Reply to
Paul Keinanen

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

Thanks. Haran.

of

of

and

a
Reply to
Haran Vela

These people make good power supplies:

formatting link

--
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
 Click to see the full signature
Reply to
Guy Macon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.