static memory allocation under msp430

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

I am programming an embbeded software on C for the MSP430.  I need to
allocate a certain
pointer to a memory position....What I am trying to do is to get some info
from my memory positions from 0x200 to 0x3c0 as volatile data.  At a certain
moment an interrupt at processor level through assembler inserts the
variables into the memory where I will read...
So far so good. The problem is that my own program overwrites this data
sometimes by writting it's own enviroment variables.
I would need a method to either allocate memory staticly or "reserve"
certain memory positions from my ram so that my program cannot mess up with
them on a dynamic memory allocation....  By the way, I am using IAR embedded

Anyone can give some light upon this?



Re: static memory allocation under msp430
No matter what tool you use:

use the volatile keyword on a global variable. Then the compiler is not
allowed to optimized in any way.


Quoted text here. Click to load it

Re: static memory allocation under msp430

Quoted text here. Click to load it

Although all C compilers I've used act this way, the C standard does not
require this behavior.

To the OP, you should ask the linker to reserve a block of RAM for you
using the linker control file. The default linker control file is used
when you build without explicitly specifiying one. I think they have the
extension .xcl for the IAR toolchain. Anyhow, copy the default one you are
using to a new name, like myproj.xcl, edit the RAM map area and create a
new section, like myReservedRam, and then tell the toolchain to link with
myproj.xcl using the correct flag to override the default .xcl file.

- Mark ->

Re: static memory allocation under msp430

With all due respect, I disagree.

If you have a look at ISO/IEC 9899:1999 to cite:

"... Program execution


Accessing a volatile object, modifying an object, modifying a file, or
calling a function
that does any of those operations are all side effects,11) which are changes
in the state of
the execution environment. Evaluation of an expression may produce side
effects. At
certain specified points in the execution sequence called sequence points,
all side effects
of previous evaluations shall be complete and no side effects of subsequent
shall have taken place. (A summary of the sequence points is given in annex

The least requirements on a conforming implementation are:
- At sequence points, volatile objects are stable in the sense that previous
accesses are
complete and subsequent accesses have not yet occurred.

11) The IEC 60559 standard for binary floating-point arithmetic requires
certain user-accessible status
flags and control modes. Floating-point operations implicitly set the status
flags; modes affect result
values of floating-point operations. Implementations that support such
floating-point state are
required to regard changes to it as side effects - see annex F for details.
The floating-point
environment library <fenv.h> provides a programming facility for indicating
when these side
effects matter, freeing the implementations in other cases.

More stringent correspondences between abstract and actual semantics may be
defined by
each implementation.

EXAMPLE 1 An implementation might define a one-to-one correspondence between
abstract and actual
semantics: at every sequence point, the values of the actual objects would
agree with those specified by the
abstract semantics. The keyword volatile would then be redundant.

Alternatively, an implementation might perform various optimizations within
each translation unit, such
that the actual semantics would agree with the abstract semantics only when
making function calls across
translation unit boundaries. In such an implementation, at the time of each
function entry and function
return where the calling function and the called function are in different
translation units, the values of all
externally linked objects and of all objects accessible via pointers therein
would agree with the abstract
semantics. Furthermore, at the time of each such function entry the values
of the parameters of the called
function and of all objects accessible via pointers therein would agree with
the abstract semantics. In this
type of implementation, objects referred to by interrupt service routines
activated by the signal function
would require explicit specification of volatile storage, as well as other


6.7.3 Type qualifiers

6 An object that has volatile-qualified type may be modified in ways unknown
to the
implementation or have other unknown side effects. Therefore any expression
to such an object shall be evaluated strictly according to the rules of the
abstract machine,
as described in Furthermore, at every sequence point the value last
stored in the
object shall agree with that prescribed by the abstract machine, except as
modified by the
unknown factors mentioned previously.114) What constitutes an access to an
object that
has volatile-qualified type is implementation-defined.

A volatile declaration may be used to describe an object corresponding to a
input/output port or an object accessed by an asynchronously interrupting
function. Actions on
objects so declared shall not be ''optimized out'' by an implementation or
reordered except as
permitted by the rules for evaluating expressions.


As you can see the ISO standard (as the successor of the ANSI X3 159-1990
standard) does require
this behaviour.

I assume that most crosscompilers for embedded targets adhere to this
At least the ones I have used so far do so. (TASKING, Keil, IAR, ...  just
to name a few).

with kind regards


Quoted text here. Click to load it

Site Timeline