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:
>> Compilation failure
FLASH size: 0x3fde unused: 0x3f14 max hole: 0x3f14
I checked the linker command file, which shows the start of flash and the size
to be correct for this MSP flavor (f235)
FLASH : origin = 0xC000, length = 0x3FDE
When I look at the map file I see the .text region starting at 0x0000, which
causes the linker error:
.text 0 00000000 00005654 FAILED TO ALLOCATE
I ran the build on the older CCS version on a different machine and the memory
sections in the linker file are at the same locations, and in the map file code
is started to be placed at 0xC000. Any ideas as to the problem?
linker issue with CCS 6
Started by ●February 3, 2016
Reply by ●February 3, 20162016-02-03
I have to just guess because you didn't disclose the linker
file, error log file, and source code here. The only fact
that you suggest is that the code used to compile and link
(and still does, I think) under an older set of compiler
tools and does not compile and link under the newest set.
(And you assert that the linker file matches the processor
correctly, that the processor is the F235, and that you are
using CCS.)
If that is the only difference then I would tend to suppose
that the C compiler either hasn't been informed correctly of
the processor you are using and therefore is making the wrong
assumptions when emitting code into the object files or else
that the C compiler has been changed so that its own
assumptions are different than before regardless of the
processor selected and that you need to place some kind of
additional in-source code lines to help it. (I'm assuming
here that there isn't any assembly code in the project.) In
the first case, you need to properly tell the IDE what
processor you are using so that the CCS toolset can properly
set up the right #define or whatever it uses to figure out
the processor type and emit correct object files. In the
latter case, you probably need to read the docs.
But I don't use CCS and haven't. So this is just an educated
observation about the general situation and not a tailored
observation based upon any specific CCS experience. Perhaps
someone here can better help you.
Jon
Posted by: Jon Kirwan
file, error log file, and source code here. The only fact
that you suggest is that the code used to compile and link
(and still does, I think) under an older set of compiler
tools and does not compile and link under the newest set.
(And you assert that the linker file matches the processor
correctly, that the processor is the F235, and that you are
using CCS.)
If that is the only difference then I would tend to suppose
that the C compiler either hasn't been informed correctly of
the processor you are using and therefore is making the wrong
assumptions when emitting code into the object files or else
that the C compiler has been changed so that its own
assumptions are different than before regardless of the
processor selected and that you need to place some kind of
additional in-source code lines to help it. (I'm assuming
here that there isn't any assembly code in the project.) In
the first case, you need to properly tell the IDE what
processor you are using so that the CCS toolset can properly
set up the right #define or whatever it uses to figure out
the processor type and emit correct object files. In the
latter case, you probably need to read the docs.
But I don't use CCS and haven't. So this is just an educated
observation about the general situation and not a tailored
observation based upon any specific CCS experience. Perhaps
someone here can better help you.
Jon
Posted by: Jon Kirwan
Reply by ●February 4, 20162016-02-04
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.
/*
----*/
/* These linker options are for command line linking only. For IDE
linking, */
/* you should set your linker options in Project Properties
*/
/* -c LINK USING C
CONVENTIONS */
/* -stack 0x0100 SOFTWARE STACK SIZE
*/
/* -heap 0x0100 HEAP AREA SIZE
*/
/*
*/
/*----*/
/* Version: 1.173
*/
/*----*/
/****************************************************************************/
/* Specify the system memory map
*/
/****************************************************************************/
MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
RAM : origin = 0x0200, length = 0x0800
INFOA : origin = 0x10C0, length = 0x0040
INFOB : origin = 0x1080, length = 0x0040
INFOC : origin = 0x1040, length = 0x0040
INFOD : origin = 0x1000, length = 0x0040
FLASH : origin = 0xC000, length = 0x3FDE
BSLSIGNATURE : origin = 0xFFDE, length = 0x0002, fill 0xFFFF
INT00 : origin = 0xFFE0, length = 0x0002
INT01 : origin = 0xFFE2, length = 0x0002
INT02 : origin = 0xFFE4, length = 0x0002
INT03 : origin = 0xFFE6, length = 0x0002
INT04 : origin = 0xFFE8, length = 0x0002
INT05 : origin = 0xFFEA, length = 0x0002
INT06 : origin = 0xFFEC, length = 0x0002
INT07 : origin = 0xFFEE, length = 0x0002
INT08 : origin = 0xFFF0, length = 0x0002
INT09 : origin = 0xFFF2, length = 0x0002
INT10 : origin = 0xFFF4, length = 0x0002
INT11 : origin = 0xFFF6, length = 0x0002
INT12 : origin = 0xFFF8, length = 0x0002
INT13 : origin = 0xFFFA, length = 0x0002
INT14 : origin = 0xFFFC, length = 0x0002
RESET : origin = 0xFFFE, length = 0x0002
}
/****************************************************************************/
/* Specify the sections allocation into memory
*/
/****************************************************************************/
SECTIONS
{
.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
*/
.bslsignature : {} > BSLSIGNATURE /* BSL Signature
*/
.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
*/
.infoA : {} > INFOA /* MSP430 INFO FLASH Memory
segments */
.infoB : {} > INFOB
.infoC : {} > INFOC
.infoD : {} > INFOD
/* MSP430 Interrupt vectors */
.int00 : {} > INT00
.int01 : {} > INT01
PORT1 : { * ( .int02 ) } > INT02 type = VECT_INIT
PORT2 : { * ( .int03 ) } > INT03 type = VECT_INIT
.int04 : {} > INT04
ADC12 : { * ( .int05 ) } > INT05 type = VECT_INIT
USCIAB0TX : { * ( .int06 ) } > INT06 type = VECT_INIT
USCIAB0RX : { * ( .int07 ) } > INT07 type = VECT_INIT
TIMERA1 : { * ( .int08 ) } > INT08 type = VECT_INIT
TIMERA0 : { * ( .int09 ) } > INT09 type = VECT_INIT
WDT : { * ( .int10 ) } > INT10 type = VECT_INIT
COMPARATORA : { * ( .int11 ) } > INT11 type = VECT_INIT
TIMERB1 : { * ( .int12 ) } > INT12 type = VECT_INIT
TIMERB0 : { * ( .int13 ) } > INT13 type = VECT_INIT
NMI : { * ( .int14 ) } > INT14 type = VECT_INIT
.reset : {} > RESET /* MSP430 Reset vector
*/
}
/****************************************************************************/
/* Include peripherals memory map
*/
/****************************************************************************/
-l msp430f235.cmd
-Bill
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.
/*
----*/
/* These linker options are for command line linking only. For IDE
linking, */
/* you should set your linker options in Project Properties
*/
/* -c LINK USING C
CONVENTIONS */
/* -stack 0x0100 SOFTWARE STACK SIZE
*/
/* -heap 0x0100 HEAP AREA SIZE
*/
/*
*/
/*----*/
/* Version: 1.173
*/
/*----*/
/****************************************************************************/
/* Specify the system memory map
*/
/****************************************************************************/
MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
RAM : origin = 0x0200, length = 0x0800
INFOA : origin = 0x10C0, length = 0x0040
INFOB : origin = 0x1080, length = 0x0040
INFOC : origin = 0x1040, length = 0x0040
INFOD : origin = 0x1000, length = 0x0040
FLASH : origin = 0xC000, length = 0x3FDE
BSLSIGNATURE : origin = 0xFFDE, length = 0x0002, fill 0xFFFF
INT00 : origin = 0xFFE0, length = 0x0002
INT01 : origin = 0xFFE2, length = 0x0002
INT02 : origin = 0xFFE4, length = 0x0002
INT03 : origin = 0xFFE6, length = 0x0002
INT04 : origin = 0xFFE8, length = 0x0002
INT05 : origin = 0xFFEA, length = 0x0002
INT06 : origin = 0xFFEC, length = 0x0002
INT07 : origin = 0xFFEE, length = 0x0002
INT08 : origin = 0xFFF0, length = 0x0002
INT09 : origin = 0xFFF2, length = 0x0002
INT10 : origin = 0xFFF4, length = 0x0002
INT11 : origin = 0xFFF6, length = 0x0002
INT12 : origin = 0xFFF8, length = 0x0002
INT13 : origin = 0xFFFA, length = 0x0002
INT14 : origin = 0xFFFC, length = 0x0002
RESET : origin = 0xFFFE, length = 0x0002
}
/****************************************************************************/
/* Specify the sections allocation into memory
*/
/****************************************************************************/
SECTIONS
{
.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
*/
.bslsignature : {} > BSLSIGNATURE /* BSL Signature
*/
.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
*/
.infoA : {} > INFOA /* MSP430 INFO FLASH Memory
segments */
.infoB : {} > INFOB
.infoC : {} > INFOC
.infoD : {} > INFOD
/* MSP430 Interrupt vectors */
.int00 : {} > INT00
.int01 : {} > INT01
PORT1 : { * ( .int02 ) } > INT02 type = VECT_INIT
PORT2 : { * ( .int03 ) } > INT03 type = VECT_INIT
.int04 : {} > INT04
ADC12 : { * ( .int05 ) } > INT05 type = VECT_INIT
USCIAB0TX : { * ( .int06 ) } > INT06 type = VECT_INIT
USCIAB0RX : { * ( .int07 ) } > INT07 type = VECT_INIT
TIMERA1 : { * ( .int08 ) } > INT08 type = VECT_INIT
TIMERA0 : { * ( .int09 ) } > INT09 type = VECT_INIT
WDT : { * ( .int10 ) } > INT10 type = VECT_INIT
COMPARATORA : { * ( .int11 ) } > INT11 type = VECT_INIT
TIMERB1 : { * ( .int12 ) } > INT12 type = VECT_INIT
TIMERB0 : { * ( .int13 ) } > INT13 type = VECT_INIT
NMI : { * ( .int14 ) } > INT14 type = VECT_INIT
.reset : {} > RESET /* MSP430 Reset vector
*/
}
/****************************************************************************/
/* Include peripherals memory map
*/
/****************************************************************************/
-l msp430f235.cmd
-Bill
Reply by ●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
>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
Reply by ●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
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 ●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"
> 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 ●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
>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 ●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
>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 ●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
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 ●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
>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
