Error lp011 section placement failed iar

I am trying to run some basic Ethernet applications (via lwIP) on an ARM Cortex M3 which is on board a M2S150 Development kit and have run into an issue I don’t understand:

Error[Lp011]: section placement failed unable to allocate space for sections/blocks with a total estimated minimum size of 0x8dc8 bytes (max align 0x8) in <[0x20008000-0x2000ffff]> (total uncommitted space 0x8000).

Upon further research some forums mentioned that the issue may be that your program does not fit in flash (which I doubt considering I am calling one function just to test things out). Other sources mentioning modifying the linker icf file, but I am not sure if this is the right way to go about it given that Libero generates the icf files when you create a IAR project and would have information on the dev board you are using.

This is the current code I am trying to run:

/* lwIP includes. */
#include "lwip/init.h"

int main(void)
{
  
  lwip_init();

  for(;;){}

  //Should never reach here.
  return 0;
}

Would anyone be able to provide some insight on why this is happening?

EDIT Added ESRAM ICF file:

/******************************************************************************/
/*  (c) Copyright 2015 Microsemi SoC Products Group. All rights reserved.     */
/*  SmartFusion2 scatter file for debugging code executing in internal eSRAM. */
/*                                                                            */
/*  SVN $Revision: 7419 $                                                     */
/*  SVN $Date: 2015-05-15 16:50:21 +0100 (Fri, 15 May 2015) $                 */
/******************************************************************************/
/* 
 * Some current (April 2015) dev kit memory map possibilities are
 * --Type-------Device-----------address start---address end----size---Dbus--RAM IC-------SF2--Comment---------------
 * --eNVM-------M2S010-----------0x60000000------0x6007FFFF-----256KB---------------------010------------------------
 * --eNVM-------M2S090-----------0x60000000------0x6007FFFF-----512KB---------------------090------------------------
 * --eSRAM------M2Sxxx-----------0x20000000------0x2000FFFF-----64KB----------------------xxx--All have same amount--
 * --eSRAM------M2Sxxx-----------0x20000000------0x20013FFF-----80KB----------------------xxx--If ECC/SECDED not used
 * --Fabric-----M2S010-----------0x30000000------0x6007FFFF-----400Kb---------------------010--note-K bits-----------
 * --Fabric-----M2S090-----------0x30000000------0x6007FFFF-----2074Kb--------------------090--note-K bits-----------
 * --LPDDR------STARTER-KIT------0xA0000000------0xA3FFFFFF-----64MB---16--MT46H32M16-----050------------------------
 * --LPDDR------484-STARTER-KIT--0xA0000000------0xA3FFFFFF-----64MB---16--MT46H32M16-----010------------------------
 * --LPDDR------SEC-EVAL-KIT-----0xA0000000------0xA3FFFFFF-----64MB---16--MT46H32M16LF---090--Security eval kit-----
 * --DDR3-------ADevKit----------0xA0000000------0xBFFFFFFF-----1GB----32--MT41K256M8DA---150------------------------
 * --Some older physical memory map possibilities are
 * --Type-------location---------address start---address end----size---Dbus---RAM IC------SF2--Comment--------------
 * --LPDDR------EVAL KIT---------0xA0000000------0xA3FFFFFF-----64MB-=-16--MT46H32M16LF---025--Eval Kit--------------
 * --DDR3-------DevKit-----------0xA0000000------0xAFFFFFFF-----512MB--16--MT41K256M8DA---050------------------------
 */
/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$configideIcfEditorcortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x20000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x20000000;
define symbol __ICFEDIT_region_ROM_end__   = 0x20007FFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x20008000;
define symbol __ICFEDIT_region_RAM_end__   = 0x2000FFFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x800;
/**** End of ICF editor section. ###ICF###*/

define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region   { readonly };
place in RAM_region   { readwrite,
                        block CSTACK, block HEAP };

SparkFun Forums

Where electronics enthusiasts find answers.

Out of ram memory when trying to debug with IAR

Out of ram memory when trying to debug with IAR #69441

PC side:
IAR Elf Linker for ARM 5.30.0.51174 (5.30.0.51174)
H-JTAG server v0.9.0

HW Side:
Olimex LPC2378STK

IAR RAM DEBUG Settings:
define symbol __ICFEDIT_region_ROM_start__ = 0x00;
define symbol __ICFEDIT_region_ROM_end__ = 0x00;
define symbol __ICFEDIT_region_RAM_start__ = 0x40000044;
define symbol __ICFEDIT_region_RAM_end__ = 0x40007FFF;
place in RAM_region < readonly >;
place in RAM_region < readwrite,
block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK,
block UND_STACK, block ABT_STACK, block HEAP >;

Error[Lp011]: section placement failed: unable to allocate space for sections/blocks with a total estimated minimum size of 0x8990
bytes in (total uncommitted space 0x7fbc)

Workaround:
To get rid of this message, I modified CSTACK from 0x2000 to 0x1000. I don’t like this but I don’t know other solution.

Another option was to increase the optimization level in debug, which I don’t want. I keep it at NONE.

What can I do because the code is not finished and is growing?

User mini profile

Baiazid

Posts: 10 Joined: Tue May 27, 2008 10:18 pm Status: Off-line Location: Australia

#71639

It’s about a month since you posted that, and I just got a similar error. Found your post by googling for the error message. Did you ever find a solution?

I’m not sure what the error message means exactly. In my case, I have

I am also using IAR Elf Linker for ARM 5.30.0.51174 (5.30.0.51174). And 5.30.0.51174 (5.30.0.51174). I guess it’s EWARM 5.30 although it installed itself in a directory called Embedded Workbench 5.4

The reason I don’t understand the error message is:

• The linker is trying to place something in the ROM region, where code lives. But I commented out some code, and the number for «uncommitted space» increased but the 0x788 did not change!
• The uncommitted space is way greater than the sections or blocks which could not be placed
• I changed the size of some variables (thinking the «mem:» bit of the message might have the region wrong) and again, only the uncommitted space changed!

The only occurrence of «0x788» in the map file, is in the error message. So I have no clue about what is not being placed.

Changing the optimisation changed the number of uncommitted bytes (it was 0x7A8 before optimisation for size was turned on), but not enough to let me compile.

The compiler version I bought is the one with 256kB code limit. But the code size is only about 160kB at the moment, so I don’t think that should matter. (Anyway, the CPU only has 256kB of flash, so I’d have bigger problems if I got up there.)

Источник

Mbed test linker Errors — IAR8 #5387

Mbed test build fails on IAR8 feature branch with below error, refer PR #5329 for more information:

Description

Target
KL25Z and KL46Z

Toolchain:
IAR8.2

The text was updated successfully, but these errors were encountered:

Is this included also with dynamic heap support for IAR8 ? I assume not.

It is with dynamic heap support. Got the issue on dynamic heap PR

Splited RAM section not compatible with dynamic HEAP. RAM define/section if splited, IAR expanding size considers just one section while heap creation which results in smaller chunk for heap.
Fixed in commit 8e57107

0xc0170 — Please add Freescale team for review

Is it functional ? I recall when we had one region (some time ago), allocation need to be aware about boundaries (no object should cross the boundary that is set to 0x2000 0000 as I recall. Limitation of their controller that does not support access independently to both RAM banks at the same time). I can not find the issue now for reference :/ That fix is the same for ARMCC and GCC, one RAM region?

@mmahadevan108 @maclobdell Can you please have a look at this issue.

We did the morph test on #5329, after fix but we do not have any KL series device in CI testing.

Limitation of their controller

As per @c1728p9, crossing boundaries should not be an issue with M0 devices. I am not sure of any controller limitation, hence would be best to have review from Freescale.

That fix is the same for ARMCC and GCC, one RAM region

Fix is applied only for IAR (dynamic heap changes). No change in ARMCC and GCC linker scripts

Источник

Build error on Bootloader example

SDK: 14.2 Software device:332(5.0.0)

I want to use a bootloader to update my APP image. So I use DFU example and change some setting as below

• /components/softdevice/s132/headers/nrf52
• /components/softdevice/s132/headers
• Defined symbols is S132

has been changed to:

• /components/softdevice/s332/headers/nrf52
• /components/softdevice/s332/headers
• Defined symbols is S332

When I build All. I got a error as below

Error[Lp011]: section placement failed

unable to allocate space for sections/blocks with a total estimated minimum size of 0x9ac3 bytes (max align 0x10) in (total uncommitted space 0x5e00).

I think that it is a flash area setting error. But I think this should not need to change

please give me a suggestion.

If I change flash setting as below, I can build successfully.

But I have another issue. if I burn this bootloader image to PCA14000 board with softdevice by nRFgo. (no application image)

I can’t saw dfu advertising on my nrf connect.

But I run debug mode by IAR as below. after press run button, I can saw dfu adverting on my nrf connect.

Источник

Error lp011 section placement failed iar

The 5.20 toolset has new features to make it possible to copy all (or most) of the code to RAM at program startup. One of these features is that the linker protects sections that are referenced from the startup code from being affected by an ‘initialize by copy’ directive, ensuring that only code that is only run after copy initialization has been finished will be copied to RAM.
In some cases, this can mean that an old project no longer works when linked with the new linker and libraries. One example is if you are supplying your own replacement for the cstartup module, based on the module in one of the 5.1X releases, and you are specifying in your ‘initialize by copy’ directive that you want the interrupt table to be copied to RAM at program startup.
To correct this you must mark the interrupt table with a special symbol, __iar_init$$done , to indicate that copy initialization is performed before it is needed. Otherwise the linker will not arrange for the interrupt table to be copied, even though it is mentioned in an ‘initialize by copy’ directive. For Cortex-M processors, you only have to do this if you are also supplying your own cmain module.

Atmel examples are in many cases written in the way described above. The fix is to place a label __iar_init$$done in front of the vector table.
Example:

In the kickstart edition, the linker will choose the basic heap implementation, that is, the same as when the linker command line option —basic_heap is used in the standard edition.

If an application is written purely in assembler language, and the runtime library is not used, the linker file must contain a do not initialize directive for each section that contains readwrite data. For example, this assembler code implies that the following directive must be present in the linker file: If the linker directive is omitted, the linker will assume that variables_section contains data which shall be initialized with zero, and will issue Error[Lp001]: no definition for init routine «__iar_zero_init3» as the runtime library is not used.

New in 7.30.3: Support for the VFP unit on Cortex-M7, both the single-precision variant and the double-precision variant

Prebuilt libraries for math functions, built for Cortex-M with a VFP unit, have new names:

Note that the same library file names are reused in 7.30.3, but with other content. This is an adaption to the naming conventions specified in the Using prebuilt libraries section of the IAR C/C++ Development Guide for ARM.

New in 7.50.1:
The bwt and lzw packing methods have been removed. Linker config files containing explicit references to these will result in a warning, and use of lz77 instead.

The linker has been changed so that it normally generates calls to smaller unpacking routines for compressed initializers, routines that can only handle a single source and destination range at a time. See the documentation for the initialize by copy linker configuration directive for more information.

The linker now emits an error when some initialization has been requested, but the program contains no reference to the initialization routine, or to the init table.
You can control which sections are automatically initialized at program startup. Sections with no content (like .bss ) are initialized to zero unless matching a section selection pattern in a do not initialize directive. Sections with content (like .data ) are initialized only if matching a section selection pattern in an initialize by copy directive.

New features

Known Problems

Building with cstartup.s will cause the MISRA C checker to incorrectly report errors.
[EW19800]

Program Corrections

Variables declared both const and __no_init are output as actual zeros by the linker. No content should be generated by the linker for these variables.
[EW25771]

ielftool has been changed so that using —srec-s3only or —srec-len automatically assumes —srec if no output format has been specified. Also, a warning is emitted for use of —srec-s3only/—srec-len if some other output format has been specified.
[EW25699]

In EWARM 7.50.2
The linker can place content in fixed order blocks in an incorrect order when some of the content is initializer data packed using the packbits or lz77 packing methods. Note that the first and last placement modifiers result in an implicit use of a fixed order block.
[EW25807]

User guide corrections

Miscellaneous

Release history

V7.40 2015-02-19

Compiler-generated annotations for stack usage analysis were lost during instruction scheduling for instructions within IT blocks. This could result in faulty stack usage analysis.
[EW25111]

The linker can terminate with an internal error after diagnosing that some absolute variables cannot be runtime-initialized because they do not meet the alignment requirements.
[EW25212]

In EWARM 7.40.2:
When performing stack usage analysis where the maximum call chain includes a recursive call nest for which a max recursion depth has been specified, the stack usage numbers for the functions in the nest can be listed on the wrong function.
[EW25264]

In EWARM 7.40.5:
The diagnostic message produced when not finding a match for a module-local symbol pattern in a stack usage control file does not make clear that the pattern can only match module-local symbols.
[EW25457]

In EWARM 7.40.5:
In some cases where a function tail calls another, the compiler fails to generate stack usage information about this call, leading to stack usage analysis errors in the linker.
[EW25463]

In EWARM 7.40.5:
When using the debug heap, references to __iar_dlmalloc_usable_size are incorrectly redirected to __iar_debug_malloc_usable_size instead of __iar_debug_dlmalloc_usable_size . This typically results in an undefined external error.
[EW25552]

In EWARM 7.40.5:
An expression containing a bit-preserving cast of the result of the __section_begin/__section_end/__segment_begin/__segment_end operators is not considered a constant expression. In (E)C++ this can result in a const variable initialized by such an expression being placed in RAM instead of in ROM.
[EW25605]

In EWARM 7.40.5:
Variables that are both __no_init and const are incorrectly generated in writable (instead of non-writable) ELF sections and counted as readwrite data in linker summaries.
[EW25627]

V7.30 2014-09-24

In EWARM 7.30.3:
The linker incorrectly warns about image input files not containing the information to support Virtual Function Elimination.
[EW24962]

In EWARM 7.30.3:
When performing stack usage analysis in the linker for a C++ program using virtual function calls, if Virtual Function Elimination is disabled for any reason, the information about possible virtual function calls is not collected, resulting in false warnings and unnecessarily imprecise stack usage output.
[EW24964]

In EWARM 7.30.3:
In some situations involving placing sections or blocks at the end of a memory range in which other sections or blocks are also placed, the linker can fail to detect when space runs out and silently place the sections or blocks in an overlapping fashion.
[EW24977]

In EWARM 7.30.3:
Section placement in the linker can fail incorrectly in cases involving many fixed size place at directives.
[EW25053]

In EWARM 7.30.4:
The builtin operators __section_begin , __section_end , etc, always return 0 for the linker-created section .iar.init_table .
[EW25073]

In EWARM 7.30.4:
When linking a configuration for loading directly into RAM, the linker can mistakenly merge read/write segments with content (initialized variables) with segments containing zero initialized or uninitialized sections, resulting in unecessarily large binary files and long load times.
[EW25091]

In EWARM 7.30.4:
The linker can terminate with an internal error after one or more normal errors in some cases involving section placement failure and sections placed at addresses dependent on the size of compressed initializers.
[EW25098]

V7.20 2014-05-19

Non-absolute root sections can be incorrectly excluded from a build when symbols defined in them are suppressed as a result of duplicate symbol definition resolution.
[EW24613]

In EWARM 7.20.2:
The last modifier has no effect when placing an overlay (as opposed to a block or section pattern) in a linker placement directive in the linker configuration file.
[EW24712]

In EWARM 7.20.2:
The linker reported a violation of MISRA C:2004 rule 5.1 within the C-RUN libraries, although the rule does not apply to system libraries.
[EW24714]

In EWARM 7.20.2:
The C-RUN debug heap function __iar_leaks_ignore_all() is not properly handled in the linker. Use __iar_debug_leaks_ignore_all() as a workaround.
[EW24728]

In EWARM 7.20.2:
Assembler root sections with one or more suppressed weak symbol definition can sometimes erroneously be dropped when linking.
[EW24757]

In EWARM 7.20.2:
The linker now handles big endian correctly when linking for Cortex-M4.
[EW24799]

In EWARM 7.20.5:
Using an except clause when defining a fixed order block does not have the intended effect.
[EW24785]

In EWARM 7.20.5:
The linker option —no_remove , to suppress unused section removal, interacts poorly with the support for C-RUN, resulting in unwanted inclusion of the global C-RUN bounds table even when not needed.
[EW24797]

In EWARM 7.20.5:
Due to a bug in the compiler, Virtual Function Elimination ( —vfe ) in the linker can incorrectly discard virtual functions referenced only from pointer to member function constants in the initializers for aggregate objects.
Example:
int (B::*arr[])() = < &B::fun >;
[EW24822]

In EWARM 7.20.5:
When using multi-file compilation ( —mfc ) in (E)C++, the linker emits spurious warnings about missing Virtual Function Elimination information in the extra (empty) object files generated by the compiler.
[EW24844]

V7.10 2014-02-21

The linker now warns about section placement patterns which do not match any sections, if there exist sections with similar names to the one used in the pattern and these sections would otherwise have been a match.
[EW24096]

In some cases involving the packing algorithm lz77 , either by default or specifically, where section placement fails, the linker can stop with an internal error after reporting the section placement failure.
[EW24179]

After emitting error Lp011 , section placement failed, the linker can terminate with an internal error.
[EW24446]

Sometimes, when a single section placement directive results in more than one content being placed into more than one address range, the linker can create multiple sections in the output file with the same name. If this output file is used with ISymExport —reserve_ranges to produce an input file for another link job, this input file can contain multiple symbol definitions with the same name, causing the later link job to fail.
[EW24456]

In EWARM 7.10.3:
When using —no_remove to keep all sections, absolute symbols with a size (like those produced by ISymExport in many cases) are not included in the output. Furthermore, using —keep has no effect on these symbols in this case.
[EW24528]

In EWARM 7.10.3:
When directed to perform Virtual Function Elimination, the linker should check that all modules contain the necessary information, and disable the optimization with a warning if any file lacks this information. This check is broken, and the linker never emits the warning and always performs the optimization when so directed, potentially resulting in a non-functioning program.
[EW24556]

In EWARM 7.10.3:
Placing an assembler label in Thumb code after the last content in a section can cause an internal error when linking.
[EW24575]

V6.70 2013-10-29

ISymExport now always includes any range reservation symbols resulting from —reserve_ranges and —ram_reserve_ranges , regardless of what is in the steering file.
[EW24132]

The linker assigns incorrect addresses to zero-initialized variables from modules compiled with gcc. The addresses are off by the alignment of each variable, which can lead to partial or complete overlap with whatever is placed after the variables.
[EW24155]

In EWARM 6.70.2:
When there are zero-initialized sections both inside and outside a movable block, an incorrect estimation for the size of the init table causes the linker to loop while creating an increasingly large output file.
[EW24228]

In EWARM 6.70.2:
The library source xwctomb.c can not be compiled with UTF-8 encoding enabled.
[EW24257]

In EWARM 6.70.2:
Linking a module containing multiple consecutive non-zero size relocations for the same location caused the linker to abort with an internal error. IAR Systems tools cannot currently produce such modules.
[EW24271]

In EWARM 6.70.2:
Multiple copies of __root __no_init absolute placed variables could be kept by the linker, leading to spurious overlap errors. The problem is not present when compiling in AEABI mode.
[EW24287]

In EWARM 6.70.2:
Sections or blocks placed with a last or first modifier immediately inside a place in directive with multiple effective address ranges can be incorrectly placed.
[EW24333, EW24391]

V6.60 2013-06-27

ielftool could fail with an incorrect «The checksum range contains uninitialized data» error when directed to perform fill/checksum calculation on an executable file with a zero-sized ROM segment.
[EW23895]

When generating a wide sum8 checksum with mirroring, ielftool only mirrored 8 bits, not the entire checksum.
[EW23921]

The linker can terminate with an internal error when linking a C++ program using exceptions with —no_remove .
[EW24673]

In EWARM 6.60.2:
ielftool does not check for overlapping sections in the input file when producing output in raw binary, which results in a very large output file containing mostly garbage.
[EW24084]

V6.50 2012-11-10

When performing Virtual Function Elimination, the linker could terminate with an internal error if a reference was made to a non-existing virtual function (this can happen if two modules have been compiled using conflicting definitions of a class). This condition is now detected and an error is generated.
[EW23038]

When linking code for ARM generation 4 processors, the possibility of fall-through veneers was not always taken correctly into account when allocating space for code sections. In particular, this could lead to an internal error if such a veneer was generated in code that was initialized by copy (through the use of the __ramfunc attribute, or via linker directives). This has been corrected.
[EW23256]

When performing stack depth analysis, the linker no longer terminates with an internal error when the program references an undefined virtual function.
[EW23299]

In some cases involving compressed initializers, the linker could place sections beyond the end of a placement range without issuing an error message. This has been corrected.
[EW23396]

iobjmanip did not preserve the address property of sections. If iobjmanip was used for removing debug information from an object file with some absolute sections, these sections were all located at address 0 in the output file. This has been corrected.
[EW23490]

The linker sometimes incorrectly calculated the space needed for compressed initializers for code in RAM that could contain veneers, especially fall-through veneers, leading to spurious Lp020 errors (compressed initializers too large to fit). This has been corrected.
[EW23551]

In EWARM 6.50.3:
The linker terminated with an internal error if any copy initialized absolute sections were needed, unless there were other (not copy initialized) absolute sections adjacent. This has been corrected.
[EW23662]

In EWARM 6.50.3:
In some cases involving recursion via a function pointer argument, the linker could crash during stack usage analysis. One case where this could happen was if one of the functions called by the printf implementation (like putchar ) could in turn call printf . This has been corrected.
[EW23696]

In EWARM 6.50.3:
There was an error in the function that attempts to place initializer bytes toward the end of sections. The result was that error Lp017 and Lp021 could be emitted in some circumstances when sections should have been placed so as to avoid this. This has been corrected.
[EW23700]

In EWARM 6.50.3:
Link jobs involving zero-sized blocks could incorrectly fail with error Lp011 (section placement failed). This has been corrected.
[EW23721]

In EWARM 6.50.4:
The library routine for unpacking compressed initializers using the lz77 packing method did not work correctly when there were multiple destination ranges. This has been corrected.
[EW23790]

In EWARM 6.50.4:
The handling of timezones that are to the west of UTC (has a negative offset in the __getzone string) did not work for the 64-bit versions of the time functions. This has been corrected.
[EW23792]

V6.40 2012-06-05

The == and != operators in linker configuration files produced incorrect results.
[EW22755]

Using two or more —image_input command line options without a symbol argument resulted in a duplicated symbol definition error for the internal linker-generated mode symbols as these were incorrectly made public in this case.
[EW22781]

Inline functions could incorrectly be considered a violation of MISRA C:2004 rule 8.10 (use statics when possible).
[EW22833]

Unclosed quoted strings in the linker configuration file caused the linker to freeze.
[EW22908]

In rare circumstances for C++ code with exceptions, the linker could emit an internal error instead of a regular error when section placement failed.
[EW23044]

Ending the line after an ISymExport steering file directive with a C-style comment caused a parse error.
[EW23079]

Using the possible calls stack usage control directive for a function performing only indirect calls via function pointers passed as arguments had no effect.
[EW23107]

The linker could crash during stack usage analysis if the program contained a function call with a constant function pointer argument for a function that could call the calling function.
[EW23127]

The packbits unpacker did not work correctly when there were multiple source or destination ranges.
[EW23134]

For some targets, the zero-init routine, and some copy-init routines, have alignment requirements on the areas they can initialize. In these cases the linker often did not correctly check that variables explicitly located at an absolute address could be initialized by the relevant routines, leading to a variety of internal errors when linking. There should now be an error for each case that is not supported.
[EW23180]

The linker now warns if the content in a place at directive is not placed at the designated address because of alignment issues.
[EW23215]

V6.30 2011-10-22

Assembler files with incorrect mode annotations — DATA , CODE16 , etc — no longer causes an internal error in the linker.
[EW22464]

Using the place at end linker directive with a block that has an alignment larger than its size no longer results in an internal error.
[EW22620]

In EWARM 6.30.3:
The linker will no longer inline symbols used by the debugger: __iar_semihosting , __iar_return_from_swi , __iar_sh_stdout_swo .
[EW22789]

In EWARM 6.30.3:
Linking a project with overlapping absolute sections (for instance from different SFRs at the same address), no longer results in one or more spurious error Lp015 (committed sections too large to fit) messages.
[EW22798]

In EWARM 6.30.3:
The heap in use is now the advanced version, dlmalloc , provided that the application refers to the heap (not counting references from library functions) and that the option —basic_heap is not used.
[EW22800]

In EWARM 6.30.3:
Absolute sections (and the symbols defined in them) could be assigned incorrect addresses by the linker. In the typical case, this would not affect the code, as references from code typically use the address directly, but it would affect the map file and the debugger. This problem has been corrected.
[EW22836]

In EWARM 6.30.3:
Providing stack usage information in a stack usage control file for a function that is present when linking, but not included in the final program, no longer causes a crash.
[EW22846]

In EWARM 6.30.5:
Using the override keyword in a stack usage control file to override the stack usage information provided in an object file no longer causes an internal error in the linker.
[EW22874]

In EWARM 6.30.5:
Incorrect region calculations involving ranges wrapping around address zero could lead to spurious emission of error Lp022 (absolute placement overlaps with previous absolute placement) and other problems. This has been corrected.
[EW22941]

V6.21 2011-07-05

V6.20 2011-04-29

Using the place at end of directive with content that includes a high-alignment section or block no longer causes an internal error.
[EW22255]

Using —strip with ielftool did not remove all debug info related ELF sections, such as string tables. Now these are also removed.
[EW22372]

V6.10 2010-11-04

The linker could crash with an internal error after issuing error Lp017 (compressed initializers needed an address that could not be determined until the size of compressed initializers is known).
[EW21191]

In some circumstances a place at directive with no needed content and a memory range partially overlapping other section placement directives could cause an internal error.
[EW21572]

If the sections/blocks in place at directives did not fit in the specified ranges, the diagnostic message produced was nonsensical. Example:
Error[Lp011]: section placement failed: unable to allocate space for sections/blocks with a total estimated minimum size of 0x0 bytes in <> (total uncommitted space 0xffffffffffff372c). Needed:
[EW21849]

C-SPY could emit a spurious «ROM size limit exceeded» error when loading Release build output from a product with a ROM size limit where some ROM usage is not counted against the limit.
[EW21909]

ielftool now uses segment data instead of section data when executing the fill and checksum functions.
[EW22329]

Iarchive now returns a proper exit status when using the silent option.
[EW21944]

V5.50 2010-04-21

Needed module-local absolute symbols were not kept by the linker, and no space was reserved for them.
Example:
static __no_init int array[10] @ 0x100;
[EW21528]

Section placement could fail when several place at commands were used in such a fashion that overlap could occur if veneers were needed.
[EW21647]

Expanding an ELF section that did not end on an even 4-byte boundary could lead to an error.
[EW21654]

In EWARM 5.50.5:
A sequence of place at section placement directives into the same memory region, where one contained compressed initializers, and a later one consisted only of blocks with no content, no longer results in an internal error in the linker.
[EW21746]

In EWARM 5.50.5:
Starting with ilinkarm 5.50.0, the linker always generated an init table section. In builds where an init table is not needed, this unnecessarily required the configuration file to contain a section placement pattern that matched the init table section. The init table section is no longer generated when it is not needed.
[EW21761]

V5.41 2009-12-14

Linking no longer fails with error Lp020 (compressed initializers too large to fit) in cases involving initialization by copy of a block of code needing veneers, where some of the code sections had a smaller alignment than the veneers.
[EW21183]

In EWARM 5.41.2:
A place in directive in a range straddling the start/end of the range of a place at directive no longer causes the linker to terminate with an internal error.
[EW21488]

In EWARM 5.41.2:
In assembly code, pc -relative instructions (like branches) referring to an absolute address no longer incorrectly results in undefined symbol errors when linking.
[EW21525]

V5.40 2009-07-10

Section placement could fail with an internal error [range allocation inconsistency] when the needed range for a place at command partially overlapped a place in command with a larger start address.
[EW20817]

When using compressed initializers with the compression algorithms packbits, lzw, or bwt, the linker cannot handle placing the destination of the initializers at an address that is dependent on the size of the initializers. Doing this resulted in an internal error but now instead results in the new error Lp021 .
[EW20842]

Including the locale.h file would force linkage with the full DLIB (including locale support). This has been corrected to only occur if locale support is actually requested.
[EW20850]

ielftool no longer crashes when using an ELF file without a symbol table as input.
[EW20883]

In some circumstances place at directives could cause linking to fail with error Lp011 (section placement failed) .
[EW20901]

When building initialization tables in link jobs with multiple zero or copy areas not inside blocks, an internal calculation error in the linker could cause section placement to fail with error Lp011 .
[EW20968, 20986]

The compiler emits debug information for an enumeration type if any of its constants are used, even if the type itself is not used. For unnamed enumeration types these constants were not visible in the debugger. Now they are.
[EW21053]

Placing the linker-generated init table using an ‘at end’ placement could result in an internal error in the linker.
[EW21065]

In EWARM 5.40.4:
The linker has been changed to assume that the automatically chosen libraries are consistent with the command line options.
[EW21201]

In EWARM 5.40.4:
ielftool now generates correct output when the input ELF file contains a segment with more than one section.
[EW21194,EW21196,EW21286]

V5.30 2009-01-23

In EWARM 5.30.2:
Linking an application with compressed initializers inside a block whose end was referenced (using __section_end or a $$Limit symbol) caused an array bounds violation in Ilink, which could result in an internal error or worse.
[EW20796]

Linking an object file with a section consisting entirely of zero-size fragments caused an internal error in the linker.
[EW19873]

When linking files where a placement was empty but had an alignment requirement, The linker could terminate with an internal error ( ApplyState — No allocation change ).
[EW20353]

Section placement could earlier fail for very small sections in some cases. Typically, this could happen when functions and variables were placed in the same memory area, and there were many calls that were close to the limit of their reach. This caused great uncertainty about how many veneers that were needed.
[EW20464]

After emitting the appropriate error message, the linker could terminate with an internal error if some sections in the program did not match any placement directive.
[EW20481]

The linker could earlier terminate with an internal error if the configuration included a place in directive and a place at directive with the same start address, and the contents of the place at directive occupied zero bytes.
[EW20656]

Compatibility checking for functions in translation units compiled without —interwork and containing a mixture of static and public functions was earlier broken in the linker, which could result in spurious compatibility errors (Lt020) as well as a failure to report such problems when they should be reported.
[EW20745]

Compressed initializers
The linker can compress initialized data to minimize flash use. The compressed data will be atomatically uncompressed when moved from flash to RAM by the startup code.

V5.20 2008-06-24

Using the export directive to export an unknown symbol from a linker configuration file no longer causes ilinkarm to terminate with an internal error after reporting the problem.
[EW19729]

ielftool can now calculate a sum32 checksum on ELF sections that have a length that is not a multiple of 4.
[EW19817]

ielftool can now perform a fill operation on ELF files that contain sections with a length that is not a multiple of 4.
[EW19835]

ilinkarm no longer fails to emit some zeroing init table entries, that caused program startup to fail to fill with zeros one or more memory ranges that should be filled with zeros.
[EW19853]

When checking MISRA C rule 23, ilinkarm no longer erroneously includes some tool internal symbols, which could result in unwanted rule violation errors.
ilinkarm also no longer crashes if error Li0005 (undefined symbol) has occurred previously.
[EW19897]

A place at directive that matches no sections and contains no blocks and which overlaps the memory region of a place in directive, no longer causes an internal error when linking.
[EW19952]
[EW20030]

When linking a project that contains overlapping ranges, ilinkarm no longer terminates with an internal error if the size of the overlap is small compared to the size of the ranges.
[EW19985]

Intel hex output from ielftool no longer contains incorrect base address records if the source ELF file contains no data before sections that start on a new base address.
[EW20031]

Copy initialization of code in a block is no longer generated incorrectly if the first thing in the block is a veneer.
[EW20040]

Chained if directives ( if. else if. else ) in linker configuration files now work correctly.
[EW20104]

The linker no longer gets an internal error (range allocation inconsistency) when a place at and a place in section placement directive use the same start address.
[EW20183]

Copy code to RAM
Improved features for copying all of the code to RAM at program startup. See above.

Position-independent veneers
The linker can generate position-independent veeners using the —pi_veneers command line option.

V5.11 2007-12-11

ilinkarm could erroneously place fall-through veneers at the start of a place at linker directive, displacing the section that was intended to end up there.
[EW19456]

ielftool (earlier ichecksum ) now handles checksums for big-endian files correctly.
[EW19466]

ielftool (earlier ichecksum ) did not recognize the arithmetic sum algorithm.
[EW19490]

In some cases, ielftool (earlier ichecksum ) did not write the checksum value to the output file.
[EW19496]

The linker erroneously included multiple definitions for the same symbol when input contained a mix of weak definitions for the same symbol, where some of the definitions used an ELF section group, and some of the definitions did not.
[EW19502]

ielftool (earlier ichecksum ) now prints an error message when the checksum placeholder variable is not defined as const .
[EW19538]

Using place at into the middle of a place in range could earlier trigger an internal error.
[EW19578]

ilinkarm sometimes reserved an extra, unneeded, byte for ‘place at’ placements.
[EW19604]

In some cases the linker could place a fall-through mode-changing veneer somewhere other than immediately preceding the destination of the veneer, resulting in non-working code.
[EW19726]

Источник

Out of ram memory when trying to debug with IAR

define symbol __ICFEDIT_region_ROM_start__ = 0x00008000;
define symbol __ICFEDIT_region_ROM_end__   = 0x0002FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x40000048;
define symbol __ICFEDIT_region_RAM_end__   = 0x40003FDF;

Error[Lp011]: section placement failed: unable to allocate space for
          sections/blocks with a total estimated minimum size of 0x788 bytes in
          <[mem:0x8000-mem:0x2ffff]> (total uncommitted space 0x1a2ac)

Доброго всем времени суток.

При переходе с IAR для STM8 версии 1.31.1 на версию 1.42.2 и выше, линкер стал выдавать нижеуказанную ошибку:

Building confikurotion: BMP085 — Debug
Updating buyld tree…
main.c stm8s_clk.c stm8s_gpio.c stm8s_y2s.c stm8s_it.c stm8s_tim4.c stm8s_uart1.c
Linking
Error[Lp011]: section plosiment foytid
unable to allocate sposi for sections/btocks wyth a total estimated minimum size of 0x2cdd bytes (max otygn 0x1) in <[0x008000-0x009fff]> (total
unsommitted sposi 0x1f80).
Error while running Linker

Total number of errors: 1
Total number of warnings: 0

Изначально проект создавался в версии 1.31.1 и НИКАКИХ ошибок не наблюдалось, а после перехода на новую версию успешно (ли???) конвертировался 1.42.2 (или 2.10.4) в новый формат и появлялась вышеуказанная ошибка.
Для чистоты эксперимента установил все три версии и пытался скомпилить проект поочерёдно на всех трёх:
1.31.1 — работает без проблем;
1.42.2 — ошибка;
2.10.4 — ошибка.

Причина ошибки в том, что изначально целевым микроконтроллером был выбран STM8S103F3 с 8кб ПЗУ, а в новых версиях код почему-то генерируется в два раза больше чем в 1.31.1: 10.8кб вместо 4.7кб.
Я перепробовал все настройки и опци оптимизации в новых версиях. Измнений ноль.
Может кто-то сталкивался с этой проблемой? Почему новый компилятор генерирует больший по объёму код при одинаковых настройках?

Заранее всем спасибо.

Hello @teetak01
I have faced the same kind of link problem for the DISCO_L475, that ‘s why I’ve created #5844.
You can apply the same modification on
mbed-os/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L476xG/device/TOOLCHAIN_IAR/stm32l476xx.icf

@@ -21,12 +21,11 @@ define region ROM_region = mem:[from __region_ROM_start__ to __region_ROM_end__]
 define region SRAM2_region = mem:[from __region_SRAM2_start__ to __region_SRAM2_end__];
 define region SRAM1_region = mem:[from __region_SRAM1_start__ to __region_SRAM1_end__];
-/* Stack 1/8 and Heap 1/4 of RAM */
-define symbol __size_cstack__ = 0x8000;
-define symbol __size_heap__   = 0xa000;
+/* Stack complete SRAM2 and Heap 2/3 of SRAM1 */
+define symbol __size_cstack__ = 0x7e00;
+define symbol __size_heap__   = 0x10000;
 define block CSTACK    with alignment = 8, size = __size_cstack__   { };
 define block HEAP      with alignment = 8, size = __size_heap__     { };
-define block STACKHEAP with fixed order { block HEAP, block CSTACK };
@@ -34,5 +33,5 @@ do not initialize  { section .noinit };
 place at address mem:__intvec_start__ { readonly section .intvec };

 place in ROM_region   { readonly };
-place in SRAM1_region   { readwrite, block STACKHEAP };
-place in SRAM2_region { };
+place in SRAM1_region { readwrite, block HEAP };
+place in SRAM2_region { block CSTACK };

Let us know if it fixes your issue and I will deploy the PR to the STM32L476 devices.