Hi,
I have two RAM regions, and want to have all unused space in one block in one region. Default behavior is to distribute unused space between blocks ("worst-fit").
But when I add "--any_placement=first_fit" I get:
Error: L6220E: Execution region RW_DTCM size (61432 bytes) exceeds limit (61423 bytes). Region contains 11 bytes of padding and 0 bytes of veneers (total 11 bytes of linker generated content).Error: L6221E: Execution region RW_DTCM with Execution range [0x20001010,0x20010008) overlaps with Execution region RW_SRAM1 with Execution range [0x20010000,0x2004fa60).
It seems as the linker forgets to include padding in its calculation of when the region is full.
"--any_contingency" does not resolve the issue.
The padding stems from some external libraries, and it cannot be avoided.
My overall goal is to have all unallocated memory in one continuous block, for use as a "my special heap".
Relevant scatter stuff:
RW_DTCM 0x20001010 0x0000EFEF { *(DMA_MEMORY) .ANY2 (+RW +ZI) } RW_SRAM1 0x20010000 0x0003FFF0 { .ANY1 (+RW +ZI) }
Linker version:
Product: MDK Essential 5.28 (Flex)Component: ARM Compiler 5.06 update 6 (build 750)Tool: armlink [4d35ed]
The linker flags in use are:
--any_contingency --any_placement=first_fit --library_type=microlib --summary_stderr --info summarysizes --map --xref --callgraph --symbols --info sizes --info totals --info unused --info veneers --strict --show_cmdline
Any pointer would be welcome :-)
Hello Henrik BS,
right, as mentioned here in the manual:
"If the linker attempts to fill a region to its limit, as it does with first_fit and best_fit, it might overfill the region. This is because linker-generated content such as padding and veneers are not known until sections have been assigned to .ANY selectors."
Regarding ""--any_contingency" does not resolve the issue." the theory is also based on the manual entry for this option:
"When a region is about to overflow because of potential padding, armlink lowers the priority of the .ANY selector."
.ANY
As your "first-fit" .ANY selector has prio 3, it is decreased to prio 2, which is still the same as the other .ANY selector's prio. That can cause, "first-fit" will still use the first .ANY selector. So the question is, what happens if you remove the priorization of the .ANY selectors?
Or maybe you can make use of the ANY_SIZE execution region attribute.
Thanks for Your suggestions,
I tried with and without ANYx priorities, the results are the same.
I did not expect ANY_SIZE to work, as my region has "stuff" + "ANY". But it turns out that ANY_SIZE is not just the size of "ANY", but rather "everything in the region except padding and veneer".
Solution:
Manually reducing the ANY_SIZE by 16 bytes. (left me with 7 bytes of unused space in this region)
RW_DTCM 0x20001010 0x0000EFEF {
Changed to:
RW_DTCM 0x20001010 ANY_SIZE 0x0000EFDF 0x0000EFEF {
It is not a beautiful solution, but it will do.
Thanks a lot.
P.S. My major concern is that somebody has to manually fiddle with these numbers in the future, and I still think a linker should be able to count padding + veneers... :-)