Re: Re: linker issue with CCS 6

On Thu, 4 Feb 2016 08:07:38 -0800, Bill wrote:

>Not much to say with regard to a log file.  The message I quoted was from
>the link stage.  The relevant line regarding the placement of the flash is
>also quoted.  There is no assembly in this project.  Here is the linker
>file.  You can see the link command at the end of the file is the correct
>device.
><snip of linker file>

The linker file looks not only correct in this line:

>:   FLASH                   : origin = 0xC000, length = 0x3FDE

But also looks very "C like" in these that follow:

>:      .bss        : {} > RAM                  /* Global & static vars              */
>:      .data       : {} > RAM                  /* Global & static vars              */
>:      .TI.noinit  : {} > RAM                  /* For #pragma noinit                */
>:      .sysmem     : {} > RAM                  /* Dynamic memory allocation area    */
>:      .stack      : {} > RAM (HIGH)           /* Software system stack             */
>:      .text       : {} > FLASH                /* Code                              */
>:      .cinit      : {} > FLASH                /* Initialization tables             */
>:      .const      : {} > FLASH                /* Constant data                     */
>:      .cio        : {} > RAM                  /* C I/O Buffer                      */
>:      .pinit      : {} > FLASH                /* C++ Constructor tables            */
>:      .init_array : {} > FLASH                /* C++ Constructor tables            */
>:      .mspabi.exidx : {} > FLASH              /* C++ Constructor tables            */
>:      .mspabi.extab : {} > FLASH              /* C++ Constructor tables            */

I don't know the syntax, but it doesn't look difficult to
work out.

So long as the C compiler _emits_ correctly assigned segments
into the object file, named as given above, then the linker
_should_ appropriately place them. It's not a complicated
process. I could describe a reasonably accurate overview in a
couple of paragraphs.

However, you say you are getting this linker error:

>:  .text      0    00000000    00005654     FAILED TO ALLOCATE

Without having the manual, I can imagine three different
interpretations to consider.

Linkers initially tend to consider EVERY segment to start at
"0", without consideration of the linker input at first. I
can easily imagine that if the linker then finds that the the
finalized size of the text section cannot be fitted into
FLASH, as there isn't enough room, that when writing out the
error message it doesn't provide an address in FLASH, but
instead writes out its previously assumed starting address
(always 0.) It couldn't get a different address, as FLASH
didn't have enough room left. Hence the above message.

Again, there is a problem in what you have provided. The
above message tells the size of .text as 00005654. (I believe
that is a reasonable presumption on my part.) But you haven't
provided ANY information on the sizes of .pinit, .cinit,
.const, .init_array, .mspabi.exidx, or .mspabi.extab, for
example. Those linker-computed sizes are IMPORTANT.

Now. Let's assume for a moment that the linker inserts the
above sections (.text, .pinit, .cinit, .const, .init_array,
.mspabi.exidx, and .mspabi.extab) in alphabetical order. (If
you read the linker documentation, they will probably clarify
this for you, one way or another.) In that case, .text would
be the LAST section to be appended into FLASH. If its size
isn't able to fit, then you very well might get exactly that
error message.

Keep in mind that you are using a different compiler with a
different library system with likely different, newer sizes
to their constructor tables, constant data and initializer
data. It wouldn't surprise me in the least to find that these
have become larger over time, now pushing your generated code
"off the end" of FLASH.

It should be pretty simple to sit down with a calculator and
the linker information on the sizes of the related sections
and figure out if they will fit. But I don't have that data.
So I can't help you verify that aspect.

I'm assuming here that the C compiler and linker aren't
broken. It's also possible they are, of course. But if so,
there is no possible way I can be of any help.

Jon


------------------------------------
Posted by: Jon Kirwan <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]