I don't think its such a bad idea to ask here about linking, since the
question is specific to the MSP430 and he is working on something that
will benefit this group.
I don't know the answer to the question, although I did look at it a
little bit when the expanded memory was first announced. I discovered
that linker scripts are more difficult to understand than I wanted to
spend time learning. My solution was to switch to ARM chips where more
memory is necessary.
Sincerely,
David Smead
www.amplepower.com
www.amplepower.net
On Wed, 11 Apr 2007, Grant Edwards wrote:
On 2007-04-11, [email protected] <[email protected]> wrote:
The latest compiler supports the extended CPU; the problem is
actually in the linker--I can't seem to make it recognise both
chunks of code space (that below and above the vectors).
Below is my original posting. I'm hoping someone knows the
answer now.
Firstly, a CPU with a non-contiguous code space is just plain
f&*cked up.
Secondly, this is a question for the binutils mailing list.
FWIW the linker will "recognize" both segments just fine. The
problem is that it recognizes them as two separate memory
segments (hey, they _are_ two separate memory segments -- blame
TI for that). AFAIK, gnu ld doesn't support non-contiguous
memory segments. [If you want an authoritative answer, ask on
the binutils mailing list.] That means that the linker script
is going to have to tell the linker which modules go in which
"text" segment.
Supporting non-contiguous memory segments in a efficient manner
is an example of the classic "bin packing problem". It's a
combinatorial NP-hard problem. That's why a CPU with
non-contiguous code space is a bad idea.
I have been using msp430-gcc for several years now and have
just started using the MSP430FG4618 with the mspgcc-win32
20070216 distribution. The ld script MEMORY configuration for
this chip looks like this:
MEMORY
{
text (rx) : ORIGIN = 0x3100, LENGTH = 0xcec0
data (rwx) : ORIGIN = 0x1100, LENGTH = 0x2000
vectors (rw) : ORIGIN = 0xffc0 LENGTH = 64
bootloader(rx) : ORIGIN = 0x0c00, LENGTH = 1K
infomem(rx) : ORIGIN = 0x1000, LENGTH = 256
infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256
}
Note that the 64 kB of program flash starting at 0x10000 is
not included, so a 116 kB chip appears to only have 52 kB of
code space. I have tried adding another MEMORY definition as
follows:
text2 (rx) : ORIGIN = 0x10000, LENGTH = 0x10000
However, I cannot find any documentation on how to specify
multiple text segments in the SECTIONS definitions.
Currently, the .text section that is mapped with "> text" to
the program flash below the vectors. I have tried ">
text,text2" and "> text and > text2" but of course they are
not proper syntax. I have also tried a single MEMORY text
definition with two origins and two lengths, but the ld syntax
doesn't permit that, either.
Can someone who groks ld enlighten me on how to gain access to
the all of the non-contiguous program flash in the new 'FG46xx
chips?
Again, why would one look to an MSP430 users mailing list for
questions on binutils linker script syntax?
--
Grant Edwards grante Yow! Darling, my ELBOW
at is FLYING over FRANKFURT,
visi.com Germany...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
