I'm able to build and debug with my code in debug mode.

But when I try to build my application in release mode I get the following linker error:
Error[e16]: Segment INTVEC (size: 0x2c align: 0x1) is too long for segment definition. At least 0xc more bytes needed.
The problem occurred while processing the segment placement command "-Z(CODE)INTVEC=FFE0-FFFF", where at
the moment of placement the available memory ranges were "CODE:ffe0-ffff"
Reserved ranges relevant to this placement:
ffe0-ffff INTVEC
Error while running Linker

Although the message is clear I dont know how to avoid this. Any input is welcome regarding the same.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

embedded2k wrote:
> I'm able to build and debug with my code in debug mode.
>
> But when I try to build my application in release mode I get the
> following linker error:
> Error[e16]: Segment INTVEC (size: 0x2c align: 0x1) is too long for
> segment definition. At least 0xc more bytes needed.
> The problem occurred while processing the segment placement command
> "-Z(CODE)INTVEC=FFE0-FFFF", where at
> the moment of placement the available memory ranges were "CODE:ffe0-ffff"
> Reserved ranges relevant to this placement:
> ffe0-ffff INTVEC
> Error while running Linker
>
> Although the message is clear I dont know how to avoid this. Any input
> is welcome regarding the same.

My guess is that you have included both your own reset vector, and the
one the library provide (from cstartup).

Make sure that the project setting like "assembler only project" are the
same for Debug and Release.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Anders Lindgren wrote:
>
> embedded2k wrote:
> > I'm able to build and debug with my code in debug mode.
> >
> > But when I try to build my application in release mode I get the
> > following linker error:
> > Error[e16]: Segment INTVEC (size: 0x2c align: 0x1) is too long for
> > segment definition. At least 0xc more bytes needed.
> > The problem occurred while processing the segment placement command
> > "-Z(CODE)INTVEC=FFE0-FFFF", where at
> > the moment of placement the available memory ranges were "CODE:ffe0-ffff"
> > Reserved ranges relevant to this placement:
> > ffe0-ffff INTVEC
> > Error while running Linker
> >
> > Although the message is clear I dont know how to avoid this. Any input
> > is welcome regarding the same.
>
> My guess is that you have included both your own reset vector, and the
> one the library provide (from cstartup).
>
> Make sure that the project setting like "assembler only project" are the
> same for Debug and Release.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
Thanks. That solved the issue.

Also there is an option for Position-independent code. What does that signify? Is it for the position independence in flash??
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

embedded2k wrote:

> Thanks. That solved the issue.

Good!
> Also there is an option for Position-independent code. What does that
> signify? Is it for the position independence in flash??

Basically yes. The compiler will not assume that the program will be
executed at the location where it was linked to. Basically, it will try
to compensate for this at direct and indirect function calls.

However, the fact that there is no system for position independent data
makes this feature quite limiting, and I would not recommend using it
unless your application have special needs.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Thu, 10 Sep 2009 16:49:44 +0200, you wrote:

>embedded2k wrote:
>
>> Thanks. That solved the issue.
>
>Good!
>> Also there is an option for Position-independent code. What does that
>> signify? Is it for the position independence in flash??
>
>Basically yes. The compiler will not assume that the program will be
>executed at the location where it was linked to. Basically, it will try
>to compensate for this at direct and indirect function calls.

In particular, the only way to achieve a position independent version
of a function call is something like this:

MOV PC, R15
ADD #SUBR, R15
CALL R15

Takes 7 cycles, 4 words, uses a register, and is a pain in the ass,
generally. A stunning oversight made by the instruction set
designer(s), most especially since they had the means to fix this
without harming anything else.

>However, the fact that there is no system for position independent data
>makes this feature quite limiting, and I would not recommend using it
>unless your application have special needs.

PC-relative addressing of scalar data can be handled using the indexed
pointer mode with the PC register. Your compiler may not support it,
as C doesn't have a _standard_ way of specifying PC-relative data so
that the compiler knows which end is up. But the processor can handle
it, just fine.

You could consider yet another extension.

Jon
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Jon Kirwan wrote:

> PC-relative addressing of scalar data can be handled using the indexed
> pointer mode with the PC register. Your compiler may not support it,
> as C doesn't have a _standard_ way of specifying PC-relative data so
> that the compiler knows which end is up. But the processor can handle
> it, just fine.
>
> You could consider yet another extension.

Accessing global data directly isn't a big problem, initializing global
pointers, on the other hand, is.

For example, if the program contains constant global variables like:

const int x;
int const * const p = &x;

How should it be initialized? Currently, this is placed into flash, and
"p" will contain the address of "x" as seen by the linker.

How should we execute something like "*p"? Should we assume that it
points to the execute location of x, or the location where the linker
originally placed it?

What if we only want to move the ROM/flash parts around, but not the RAM
part?

In addition, the PC relative mode doesn't work that well on a 430X, as
the wrap-around comes into play for some instructions. The semantics of
the PC-relative addressing mode depends on whether the instruction is
executed in the lower 64K or not.

Note that we live in a world without load formats that contain
relocation information. All position independence handling must be done
be clever coding of data representations and code. I have yet to find a
good scheme for position independence data that does not cost too much
in terms of code size overhead and global base pointer registers. If
someone has a scheme that works, I would be happy to implement it.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Dear Anders,

Accessing data and functions from volatile ROM locations (data and functions
on these locations is changed by other programs) is becoming a major
requirement.

Most flash micons have internal reprogramming capability using communication
ports.

In future FRAM may become what Flash is today.

You need to work on this quickly on solving this compilation issue.

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of
Anders Lindgren
Sent: 11 September 2009 14:27
To: m...@yahoogroups.com
Subject: Re: [msp430] Re: Release Build Error

Jon Kirwan wrote:

> PC-relative addressing of scalar data can be handled using the indexed
> pointer mode with the PC register. Your compiler may not support it,
> as C doesn't have a _standard_ way of specifying PC-relative data so
> that the compiler knows which end is up. But the processor can handle
> it, just fine.
>
> You could consider yet another extension.

Accessing global data directly isn't a big problem, initializing global
pointers, on the other hand, is.

For example, if the program contains constant global variables like:

const int x;
int const * const p = &x;

How should it be initialized? Currently, this is placed into flash, and
"p" will contain the address of "x" as seen by the linker.

How should we execute something like "*p"? Should we assume that it
points to the execute location of x, or the location where the linker
originally placed it?

What if we only want to move the ROM/flash parts around, but not the RAM
part?

In addition, the PC relative mode doesn't work that well on a 430X, as
the wrap-around comes into play for some instructions. The semantics of
the PC-relative addressing mode depends on whether the instruction is
executed in the lower 64K or not.

Note that we live in a world without load formats that contain
relocation information. All position independence handling must be done
be clever coding of data representations and code. I have yet to find a
good scheme for position independence data that does not cost too much
in terms of code size overhead and global base pointer registers. If
someone has a scheme that works, I would be happy to implement it.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Ajesh GUPTA wrote:
> Accessing data and functions from volatile ROM locations (data and functions
> on these locations is changed by other programs) is becoming a major
> requirement.
>
> Most flash micons have internal reprogramming capability using communication
> ports.
>
> In future FRAM may become what Flash is today.
>
> You need to work on this quickly on solving this compilation issue.

Absolutely, but that is a totally different issue compared to position
independent code and data.

FRAM data should be easy to implement, basically all that is needed is
to make sure that we do not perform the traditional copy from read-only
memory to RAM.

When it comes to "volatile code", i.e. code that can be updated, is that
it falls on the application to decide which parts of an application
should be updateable, and how this should be done (e.g. via a table of
function pointers).

What is needed is some kind of design guideline for this. I do not know
if you need any tool support at all for this.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I am already in touch Wilhelm =C4retun at IAR who has committed this
implementation in next version of IAR.

=20

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of
Anders Lindgren
Sent: 11 September 2009 16:56
To: m...@yahoogroups.com
Subject: Re: [msp430] Re: Release Build Error

=20

=20=20

Ajesh GUPTA wrote:
> Accessing data and functions from volatile ROM locations (data and
functions
> on these locations is changed by other programs) is becoming a major
> requirement.
>=20
> Most flash micons have internal reprogramming capability using
communication
> ports.
>=20
> In future FRAM may become what Flash is today.
>=20
> You need to work on this quickly on solving this compilation issue.

Absolutely, but that is a totally different issue compared to position=20
independent code and data.

FRAM data should be easy to implement, basically all that is needed is=20
to make sure that we do not perform the traditional copy from read-only=20
memory to RAM.

When it comes to "volatile code", i.e. code that can be updated, is that=20
it falls on the application to decide which parts of an application=20
should be updateable, and how this should be done (e.g. via a table of=20
function pointers).

What is needed is some kind of design guideline for this. I do not know=20
if you need any tool support at all for this.

-- Anders Lindgren, IAR Systems
--=20
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I've been a bit busy of late and wanted to get back to these points
you made, Anders. I'm going to dash these off quickly and I hope I
don't make any gross errors. But this isn't my area, just a hobby
interest of mine. So forgive me if I expose some profound errors in
reasoning.....
On Fri, 11 Sep 2009 10:56:59 +0200, Anders [of IAR] wrote:

>Jon Kirwan wrote:
>
>> PC-relative addressing of scalar data can be handled using the indexed
>> pointer mode with the PC register. Your compiler may not support it,
>> as C doesn't have a _standard_ way of specifying PC-relative data so
>> that the compiler knows which end is up. But the processor can handle
>> it, just fine.
>>
>> You could consider yet another extension.
>
>Accessing global data directly isn't a big problem, initializing global
>pointers, on the other hand, is.
>
>For example, if the program contains constant global variables like:
>
> const int x;
> int const * const p = &x;
>
>How should it be initialized?

I understand the above syntax and semantics and I think I gather your
point. But maybe not. Let me expose what I'm thinking and see if it
agrees with you.

Before I do, though, I just want to mention that 'x' as shown above is
a definition and a declaration and that since 'x' doesn't have an
initializer there is probably already a difficulty with the code.
Perhaps you wanted to say:

extern const int x;
int const * const p = &x;

That aside...

Currently, I take it that you access 'x' via something like this:

mov.w &x, R15

An absolute reference.

Currently, I take it that you'd access 'x' via 'p' something like
this:

mov.w &p, R15
mov.w 0(R15), R15

An absolute reference to get 'p's value into R15 and then an absolute
reference via R15 on the assumption that 'p' contains an absolute
address and not a pc-relative one.

I've avoided dealing with the const qualifiers much. I think your
comment says these are placed in flash, or may be, by your compiler.
Not surprising and it seems a good policy where that works out.

So I gather you imagine this represents a problem because 'p' is
actually, in effect, part of the constant text section (which includes
code as well as const initialized data) that can be placed in flash
and that if that constant text section is moved, that this represents
a serious problem.

I'm not sure I agree, but I think I do see an issue you present.

Ignoring the fact that your tools support linker segments which can be
any size at all, I imagine your c compiler targeting the following
basic semantic sections (I'll ignore COMMON, for now):

TABLE 1:
Section Class Section Name Section Description
- ------------- ------------ -------------------
I flash ROM CODE Code
D flash ROM CONST Constant data
D flash ROM INIT_copy Copy of init data
D volatile RAM INIT Initialized data
D volatile RAM BSS Uninitialized data
D volatile RAM HEAP Heap
D volatile RAM STACK Stack

This is a von Neumann, so there is no need to copy the CONST section
in flash to the separate volatile RAM memory region. But there is a
need to copy initialized data from flash to ram, prior to calling
main(). Is that about right?

I'm trying to set things up to understand your point more precisely.
Let me know if I am getting things wrong. Let me return to something
similar to what you originally wrote (and dispose of it, moving on.)

const int x= 5;
int const * const p = &x;

In this case, if both statements are "in view" for the c compiler,
then any use of (*p) can simply be the constant 5. So it's pointless
to discuss this case. The c compiler can "see through" the pointer
variable at compile time and doesn't need to generate any code
referencing 'p'. In fact, in some cases the c compiler may actually
be able to dispose of 'p' entirely, as it may be entirely unnecessary.
So now lets move to this:

extern const int x;
int const * const p = &x;

Now we've blocked the c compiler's ability to see the value of 'x'.
All it has is a declaration and it cannot see what constant value it
has. However, since 'p' is itself const pointer to 'x' and so far as
this example goes there are no other reasons why the c compiler needs
a definition for 'p', the c compiler can again eliminate 'p' (it's a
constant pointer to 'x') and simply use a reference to 'x' (the value
of &x) in any code specifying (*p). They are equivalent, I'd imagine.
Again, 'p' can be stripped away from the final binary object. So that
merely means that 'x' can be referenced symbolically with PC-relative
references as in:

mov.w x, r15

Which doesn't make much of a point, yet, on your side. I'd just argue
so far that you use symbolic references and drop the use of absolutes.

So let me modify the question more:

extern const int x;
extern const int * const p;

Okay. Now the c compiler doesn't know what 'p' points at (we do, you
and me, but it doesn't) but it does know that 'p' resides in flash and
that what 'p' points at also resides in flash. (As I gather from your
comments, earlier, anyway.) But it must use 'p' to find what you and
I know will be 'x'.

Well, both 'x' and 'p' are placed in the CONST section. That's their
physical location. And 'p' must only refer to something else in the
CONST section. Since CONST is always linked together into a binary
object with CODE and INIT_copy, the relative position of 'p' and 'x'
are both completely known at link time. So isn't it possible to use a
relative address, based upon some assumed relative placement and use
some code like this:

mov.w p, r15 ; use pc-relative symbolic mode to get 'p'
.
.
.
add.w pc, r15 ; add (PC-$) to generate the absolute
add.w @pc+, r15 ; address from a pc-relative one.
me EQU $
dw 2-me
mov.w @r15, r15 ; get (*p)
.
.
.

(I can't get your assembler to like "2-$" the way I want it to, so I
trick it this way.)

Here, 'p' is assumed to have an address that is relative to some
assumed load point or base position (perhaps zero?) The following
calculation adds the current (PC-$) expression to it. Normally, PC-$
should work out to zero if the code hasn't been moved around from the
linker assumptions about it. But if the code is moved, then this will
compute an adjustment that is then applied to the relative reference
in 'p'.

Could you address yourself to the points above?

All this gets more interesting, though, when you move away from purely
CONST instances. Pointers might point into writable variables, which
have to be located in ram, not in flash. And the concept of position
independence gets more interesting to me there.

Would you like to discuss that, as well? I think I know of a useful
syntax to capture all of this into useful form. But I am not sure I'm
gathering everything you wanted at the outset. So I'd better stop
here before I dig myself into a deeper hole than I have already and
let you comment, first.

Jon
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:

add.w #(2-$), r15

The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If I
instead use:

dw 2-$

I get exactly what I'd expect to see. Similarly, if I write:

h EQU $
add.w #(2-h), r15

Then I also get what I expect.

Also,

add.w #($-2), r15

gives me what I expect, too.

I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something I'm
missing. Can anyone give me a kick in the head, here, and straighten
me out?

I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes

Thanks,
Jon
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )