With Processor Expert projects it is very easy to change the heap and stack size: There is a setting for this in the Cpu component settings, under the ‘Build options’ tab:
As there is no Processor Expert in the NXP Kinetis SDK V2.0 (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“), how to do the same in a SDK V2.0 project?
GNU Linker File
The Kinetis SDK approach is to have some optional settings in the source files which are used in the linker (.ld) file. Open the linker file, and there should be something like this:
with:
HEAP_SIZE = DEFINED(__heap_size__) ? __heap_size__ : 0x100; STACK_SIZE = DEFINED(__stack_size__) ? __stack_size__ : 0x0400;
So if in the project settings there is a symbol __heap_size__ or __stack_size__ defined, then it will use these values. If not, it uses the default value (0x100 or 0x400 in above example).
Linker Map File
If I want to check what is actually used, I can check the linker map file (.map, usually located in the output (debug) folder):
In the above example I can see that 0x100 for the heap and 0x400 for the stack is used.
Defining Linker Symbols
So how to define the linker symbols?
I can use the following linker option (see “Overwriting Symbols in the GNU Linker File“) for example to specify the heap size:
-Xlinker -defsym=__heap_size__=0x600
So I can add the following to adjust the stack and heap size:
-Xlinker -defsym=__heap_size__=0x1000 -Xlinker -defsym=__stack_size__=0x100
Checking now the .map shows that the value is taken into account:
And that the new size is indeed used:
Summary
With the linker files used in the NXP Kinetis SDK V2.0 project, I can use the
-defsym
Linker command line option to overwrite symbols in the linker script, for example to configure the heap and stack size. That way I can keep the same linker file for multiple projects, and the command line to the linker is used for custom settings.
Happy stacking and heaping 🙂
What about combined STACK/HEAP — a single RAM allocation for stack and heap to claim from opposite ends?
Under Keil uVision (V5.10.0.2 to be precise) with ProcessorExpert v10.2, and with some digging by my comrade Greg Ross (kudos!), we found we could make a single allocation for both to share.
In {projectname}/Project_Settings/Linker_Files/{projectname}.scf[*footnote] we can, first of all, enable preprocessor math with the shebang top line …
#! armcc -E
… and then by trial and error we find the largest leftover RAM we can afford with this .scf language (here for our KL16 project) …
“””
#define STACKHEAP_size 3820
#define m_flash_start 0x00000000 // so m_flash_end would be same as m_flash_size
#define m_flash_size 0x00020000 // (=131072.)
#define m_text_start 0x00000410 // original (and still is) start address
#define m_text_size ( m_flash_size – m_text_start ) /* == 0x1FBF0 (=130032.) */
#define m_data_start 0x1FFFF000
#define m_data_size 0x00004000
LR_m_text m_text_start m_text_size { ; load region size_region
ER_m_text m_text_start m_text_size { ; load address = execution address
*(InRoot$$Sections)
.ANY (+RO)
}
RW_m_data m_data_start m_data_size-STACKHEAP_size { ; RW data
kl16ftfa.o
.ANY (+RW +ZI)
}
ARM_LIB_STACKHEAP m_data_start+m_data_size EMPTY -STACKHEAP_size { ; Stack region growing down and heap growing up
}
}
“””
Furthermore, we can obtain the stack(/heap) limits at execution time, to know how much stack we have, or, here, to preload the stack area with breadcrumbs that we might look for later …
“””
printf( “&Image$$ARM_LIB_STACKHEAP$$ZI$$Base=%p \n”, &Image$$ARM_LIB_STACKHEAP$$ZI$$Base ) ;
printf( “&Image$$ARM_LIB_STACKHEAP$$ZI$$Limit=%p \n”, &Image$$ARM_LIB_STACKHEAP$$ZI$$Limit ) ;
for( pb = (byte_t*)&Image$$ARM_LIB_STACKHEAP$$ZI$$Base ; (unsigned int)pb < ( __current_sp() – 4 ) ; pb++ ) {
*pb = bCANARY_SALT( pb ) ;
}
"""
… um, where bCANARY_SALT( address ) returns a diversified but determinate pattern.
SO THE POINT OF MY POST would be, how might we accomplish as much in this post-ProcessorExpert era?
*Footnote [.scf stands for "Scatter Control File"; but it is a three-letter extension that Windows Explorer insists on hiding!!!]
LikeLike
Hi Pete,
that’s an interesting approach! I did not know about the
#! armcc -E
thing which can be very handy. I know that Energy Micro projects use an interesting approach with simply setting the stack pointer at the end of the available RAM. There is still the issue that it might spill over into the variables area, but that way at least the maxiumum of available RAM is left to the startup stack.
LikeLike
Hi Erich.
How I can use processor expert and your componentes with SDK 2.0?
LikeLike
Hi Juan,
This reminds me that I should finish writing that article. But there was not enough time available this week-end to finish it :-(.
Erich
LikeLike
Rather than entering the extra flags in the “Other Flags” field at the bottom, it’s cleaner and more visible to just enter (for instance) “-defsym=__heap_size__=0x2000” (no quotes) in the large Linker Flags field at the top. You can then verify that -Xlinker -defsym=__heap_size__=0x2000 is being inserted into the command line by looking at the resulting command line under Cross ARM C++ Linker / All options. Doing it this way worked fine for me (using KDS 3.2.0).
LikeLike
Hi David,
thanks for sharing! This is indeed another method for setting the heap size :-).
LikeLike
Hi Erich, I’ve been struggling lately on trying to understand some concepts that are new for me on the ARM Cortex M world. I’m coming from HCS08 architecture as my favorite and the one I’ve mastered over more than 8 years, but every now and then when I choose a Kinetis MCU for a project I find new concepts, such as the heap. I understand completely what the stack is for, when it’s used, what is stored there, when is released, etc. But the heap is completely new for me. I’ve searched for an explanation of what it is good for but haven’t found anything. Could you point me to any document where I can learn about it? Thanks.
LikeLike
The ‘heap’ exist for the HCS08 as well, but is rarely used. It is mostly used by the C library dynamic memory allocation (malloc() and free()), for C++ as well for other dynamic data structures needed by the library or the application. So on most embedded systems, where no malloc() is used, the heap size can be zero and is not needed. As a pointer for reading: https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
I hope this helps,
Erich
LikeLike
Thank you so much Erich, now I get it.
LikeLike