Error[Lp011]: section placement failed: unable to allocate space for sections/blocks with a total estimated minimum size of 0x8990 bytes in <[mem:0x40000044-mem:0x40007fff]> (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?
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
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;
and the error message says
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]> (total uncommitted space 0x1a2ac)
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.)
It may be a linker bug. A directive added to the .icf file seems to have made it go away.
Situation is this: I have some external memory attached to my CPU. It’s declared in the .icf file as BIGRAM:
define region XRAM_region = mem:[from 0x83000000 size 0x20000];
…
place in XRAM_region { readwrite section BIGRAM };
Now, I noticed that the startup code was trying to initialise variables in this area; this is bad because the memory is not available until I initialise the BCFG registers in the LPC2294, to set up address and data bus timing and generally enable access to the RAM. I had __no_init before the variable declarations, but they were still being initialised.
So I emailed IAR, and they told me to add
do not initialize { section BIGRAM };
to the .icf file.
In addition to removing the initialisation of the variables in the RAM, my program now compiles.
If I get some time to create a test scenario that demonstrates this problem, I’ll email that to IAR. But that won’t happen for a while, if ever.