Reply by "Jon...@infinitefactors.org [msp430]" February 11, 20162016-02-11
On Thu, 11 Feb 2016 08:54:38 -0800, Bill wrote:

>So the problem was the CCS6 settings defaulted to "elf" output format, but
>the original build was in "legacy Coff". The reason why the change of
>output format from "legacy COFF" to "eabi (ELF)" causes the code size bloat
>is that the code calls log10, sqrt and pow which take double arguments. In
>COFF double is 32-bits but is 64-bits in ELF. So the issue was .text was
>looking like it was trying to be placed at 0x0 in the map file, but 0x0 was
>just a placeholder as the code would not fit. Change the output to "legacy
>Coff" and the project builds fine...
>
>-Bill

Thanks Bill. That's not something I could have guessed at.
But it is very useful to be aware of. Update appreciated!

Jon

Posted by: Jon Kirwan




Beginning Microcontrollers with the MSP430

Reply by "Wil...@gmail.com [msp430]" February 11, 20162016-02-11
So the problem was the CCS6 settings defaulted to "elf" output format, but
the original build was in "legacy Coff". The reason why the change of
output format from "legacy COFF" to "eabi (ELF)" causes the code size bloat
is that the code calls log10, sqrt and pow which take double arguments. In
COFF double is 32-bits but is 64-bits in ELF. So the issue was .text was
looking like it was trying to be placed at 0x0 in the map file, but 0x0 was
just a placeholder as the code would not fit. Change the output to "legacy
Coff" and the project builds fine...

-Bill
Reply by "lex...@gmail.com [msp430]" February 6, 20162016-02-06
Might be obvious, but you have checked the optimisation settings in the compiler are the same after the upgrade? Might explain why the code is larger now.
Reply by "Jon...@infinitefactors.org [msp430]" February 5, 20162016-02-05
On Fri, 5 Feb 2016 10:01:50 -0800, you wrote:

>yes, all outputs are in hex.

Then what about David's comment about the fact that the F235
has 0x4000 bytes of flash and the reported figure for .text
is then 0x5654? (I'd assumed it was decimal; my mistake.)

>The program actually is about 13K in debug mode.

I won't doubt your figure, but the line you reported does
say:

.text 0 00000000 00005654 FAILED TO ALLOCATE

Which, ignorant as I am about your tools, would seem to
differ with your above comment about it being actually 13K.

>Bear in mind this is a production load, I just upgraded the
>tools...works fine with CCSv5.

I believe you and I think you made that clear, earlier.

>I have a call in to TI, just thought
>someone might have done the same thing as I did and discovered the
>problem/fix.

Okay. But don't rely on that in order to move forward. You
need to own the solution here, regardless. If you want to use
the newer tools. Keep in mind that .text includes a number of
other segments, the sizes of which you also haven't
mentioned. What I'd like to see is the memory map/segment
sizes for each of them in CCSv5 and also your later version.

I have to say I remain confused about your comment that the
program is 13K in debug mode -- unless you are talking here
about the CCSv5 case, in which case it would suggest that the
newer version is generating a larger size given your reported
error line.

>I will update the group once I have a chance to chat to TI...

I'll be interested in what you do find out. Thanks for
considering an update, here.

Jon

Posted by: Jon Kirwan




Reply by "Wil...@gmail.com [msp430]" February 5, 20162016-02-05
yes, all outputs are in hex. The program actually is about 13K in debug
mode. Bear in mind this is a production load, I just upgraded the
tools...works fine with CCSv5. I have a call in to TI, just thought
someone might have done the same thing as I did and discovered the
problem/fix. I will update the group once I have a chance to chat to TI...

-Bill
Reply by "Jon...@infinitefactors.org [msp430]" February 5, 20162016-02-05
On Thu, 04 Feb 2016 14:25:31 -0800, I wrote:

>On Thu, 4 Feb 2016 13:53:56 -0600, you wrote:
>
>>On 02/03/2016 10:07 AM, w...@gmail.com [msp430] wrote:
>>>
>>>
>>> I have installed the latest dev env from TI to debug some older code.
>>> When I build, the link stage fails with this message:
>>>
>>>
>>> "../lnk_msp430f235.cmd", line 96: error #10099-D: program will not fit
>>> into available memory. placement with alignment fails for section
>>> ".text" size 0x5654 . Available memory ranges:
>>
>>The text size is 0x5664 which is a serious problem for a part that has
>>only 16K.
>>
>>You will have to either reduce the code size or switch to a part with
>>more memory.
>
>Ah. So that number is in hex, not decimal.

Sorry. Meant that as a question. From the OP's post:

.text 0 00000000 00005654 FAILED TO ALLOCATE

So, the line reports it as a hex value?

Jon

Posted by: Jon Kirwan




Reply by "Jon...@infinitefactors.org [msp430]" February 4, 20162016-02-04
On Thu, 4 Feb 2016 13:53:56 -0600, you wrote:

>On 02/03/2016 10:07 AM, w...@gmail.com [msp430] wrote:
>> I have installed the latest dev env from TI to debug some older code.
>> When I build, the link stage fails with this message:
>> "../lnk_msp430f235.cmd", line 96: error #10099-D: program will not fit
>> into available memory. placement with alignment fails for section
>> ".text" size 0x5654 . Available memory ranges:
>
>The text size is 0x5664 which is a serious problem for a part that has
>only 16K.
>
>You will have to either reduce the code size or switch to a part with
>more memory.

Ah. So that number is in hex, not decimal.

Jon

Posted by: Jon Kirwan




Reply by "'Da...@earthlink.net [msp430]" February 4, 20162016-02-04
On 02/03/2016 10:07 AM, w...@gmail.com [msp430] wrote:
> I have installed the latest dev env from TI to debug some older code.
> When I build, the link stage fails with this message:
> "../lnk_msp430f235.cmd", line 96: error #10099-D: program will not fit
> into available memory. placement with alignment fails for section
> ".text" size 0x5654 . Available memory ranges:

The text size is 0x5664 which is a serious problem for a part that has
only 16K.

You will have to either reduce the code size or switch to a part with
more memory.
--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving


Posted by: "David W. Schultz"




Reply by "Jon...@infinitefactors.org [msp430]" February 4, 20162016-02-04
It would be interesting for you to try modifying the linker
file using the GROUP option. See section 8.5.7.1 of the
MSP430 assembler manual:

http://www.ti.com/lit/ug/slau131l/slau131l.pdf

"The SECTIONS directive's GROUP option forces several output
sections to be allocated contiguously and in the order
listed, unless the UNORDERED operator is used."

See if that gets you a different error message.

Jon

Posted by: Jon Kirwan




Reply by "Jon...@infinitefactors.org [msp430]" February 4, 20162016-02-04
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.
>

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