- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have been running into problems associated with code size and wondered if we could get clarification on the maximum memory available for code and data?
I saw on another forum post it mentioned that the maximum code size is 30K. Does that pertain to the "Total RAM footprint" line in the buld console? If so it's not quite right because we found that our system stopped working completely after our total ram footprint exceeded 27364. This makes me nervous because unless I understand the actual limit I might see less predictable failures!
So my questions are:
(1) What is the maximum code size and how can I tell whether I am reaching it?
(2) What is the maximum stack size?
(3) What is the amount of space available for global and static variables?
Are there any built in functions of the stack that can be turned off to save space, for example if I disable the battery status profile does that cut down on the footprint?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
(1) What is the maximum code size and how can I tell whether I am reaching it?
[JT] -
- Use cfa_mm_MemFreeBytes as described in Glucose application doesnt seem to be running properly
- Please see Block Diagrams below for a brief Memory Map explanation.
(2) What is the maximum stack size?
[JT] - The app thread stack size is 1K (1024 bytes).
(3) What is the amount of space available for global and static variables?
[JT] - The app code + globals (initialized and zero-initialized) all share the same space. So allocating more globals will reduce space for app code and vice-versa.
(4) Are there any built in functions of the stack that can be turned off to save space, for example if I disable the battery status profile does that cut down on the footprint?
[JT] - No, here's why
- Disabling battery monitor will not give you more space because its in the ROM.
- The next version of our chip will enable some of these features.
Notes:
- The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.
- The ‘total RAM footprint ‘ line at the end of the build is only the static portion of the app + patches (includes code + initialized and uninitialized data) in our flat memory model.
- So you cannot take the app start address and add the app size and then subtract from 60K to get remaining size. See block Diagram below:
Below is a brief overview of the RAM Memory Map of the BCM20732:
This is a top level explanation and some components:
- The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.
- Note that our Stack (YELLOW) is 30K and is DATA ONLY.
- The Patches Section (Features,Updates, etc) is combined with the User App but:
- The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded.
- The App_Init/BLE_SET_CONFIG is also overlayed by the Dynamic Allocation.
As an example, we take the Hello_Senor App and using the SDK Console Window, we see the Patches Start/End Addresses:
And finally, we can see the Overlap in the code:
Hopefully this gets you started.
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
(1) What is the maximum code size and how can I tell whether I am reaching it?
[JT] -
- Use cfa_mm_MemFreeBytes as described in Glucose application doesnt seem to be running properly
- Please see Block Diagrams below for a brief Memory Map explanation.
(2) What is the maximum stack size?
[JT] - The app thread stack size is 1K (1024 bytes).
(3) What is the amount of space available for global and static variables?
[JT] - The app code + globals (initialized and zero-initialized) all share the same space. So allocating more globals will reduce space for app code and vice-versa.
(4) Are there any built in functions of the stack that can be turned off to save space, for example if I disable the battery status profile does that cut down on the footprint?
[JT] - No, here's why
- Disabling battery monitor will not give you more space because its in the ROM.
- The next version of our chip will enable some of these features.
Notes:
- The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.
- The ‘total RAM footprint ‘ line at the end of the build is only the static portion of the app + patches (includes code + initialized and uninitialized data) in our flat memory model.
- So you cannot take the app start address and add the app size and then subtract from 60K to get remaining size. See block Diagram below:
Below is a brief overview of the RAM Memory Map of the BCM20732:
This is a top level explanation and some components:
- The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.
- Note that our Stack (YELLOW) is 30K and is DATA ONLY.
- The Patches Section (Features,Updates, etc) is combined with the User App but:
- The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded.
- The App_Init/BLE_SET_CONFIG is also overlayed by the Dynamic Allocation.
As an example, we take the Hello_Senor App and using the SDK Console Window, we see the Patches Start/End Addresses:
And finally, we can see the Overlap in the code:
Hopefully this gets you started.
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thank you, this is super helpful!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi JTate -
Thanks for the very useful info.
Three questions:
(1) In the first diagram it suggests that the maximum size of an app should be 26K?
(2) Is there any way to estimate the amount needed for 'dynamic allocation' in that first diagram?
I am concerned that if we end up with a total ram footprint of 26K we would still get overruns or other problems?
Is "dynamic allocation" actually from a static buffer for which the size is known and included in the footprint?
(3) static vars that are _NOT_ initialized end up in the data area, so
static char x[20];
would be in the data area, correct? If it _IS_ initialized, does it take up space in both, or does it simply point into the code space region?
Thanks!!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
- In the first diagram it suggests that the maximum size of an app should be 26K?
- [JT] - 26K is a good approximation because it really depends on what (HW/drivers/features) the app initializes and uses.
- [JT] - cfa_mm_MemFreeBytes() is the ultimate authority on the amount of RAM available.
- Is there any way to estimate the amount needed for 'dynamic allocation' in that first diagram?
- [JT] - Not really, this is allocated for OS buffers, TX and RX buffers, stack buffer pools, thread stacks, callback registrations etc.
- I am concerned that if we end up with a total ram footprint of 26K we would still get overruns or other problems?
- [JT] - Yes.
- Since static variables that are NOT initialized end up in the data area:
- [JT] - The ‘Data ONLY’ area in yellow is the data area allocated by the BLE stack that’s in the ROM, So nothing new goes in here.
- [JT] - All application data (RW - Read_Write and ZI - Zero_Initialized variables) and application code (Code and Contants) goes into the same region in the RAM - the RED area that overlaps with Patches_InitCode.
- Do the static vars that are NOT initialized end up in the data area?
- [JT] - No, all initialized globals are initialized in place during boot.
- [JT] - So after we copy once, then what?
For Example:
- Initialized globals have to have some value before the app initializes.
- So, NOW, the initialization value is in the EEPROM/Serial FLASH and at boot, the value is copied to the RAM address and then the app can overwrite it if it likes.
- Code Example:
UINT32 my_array_of_initialized_bytes[4] = {1, 2 ,3, 4};
UINT32 my_array_of_uninitialized_bytes[4];
void_app_create(void)
{
// Print both arrays before app init
ble_trace4(“my_array_of_uninitialized_bytes has: %d, %d, %d, %d\n”, my_array_of_uninitialized_bytes[0], my_array_of_uninitialized_bytes[1], my_array_of_uninitialized_bytes [2], my_array_of_uninitialized_bytes[3]);
// Change some values.
my_array_of_initialized_bytes[0] = 4;
my_array_of_uninitialized_bytes[0] = 5;
// Print both arrays
ble_trace4(“my_array_of_initialized_bytes now has: %d, %d, %d, %d\n”, my_array_of_initialized_bytes[0], my_array_of_initialized_bytes[1], my_array_of_initialized_bytes[2], my_array_of_initialized_bytes[3]);
ble_trace4(“my_array_of_uninitialized_bytes now has: %d, %d, %d, %d\n”, my_array_of_uninitialized_bytes[0], my_array_of_uninitialized_bytes[1], my_array_of_uninitialized_bytes [2], my_array_of_uninitialized_bytes[3]);
}
This will print:
my_array_of_initialized_bytes has: 1, 2, 3, 4
my_array_of_uninitialized_bytes has: 0, 0, 0, 0
my_array_of_initialized_bytes now has: 4, 2, 3, 4
my_array_of_uninitialized_bytes has: 5, 0, 0, 0
Hope this helps
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
How do we judge the RAM overrun from the compiling output?
Can we judge it from the end address of Application?
Cause somehow I managed to have code running as usual after removal of several debugging print-out.
i.e.
--------------------------------------------------------------------------------
Patches start at 0x00205918 (RAM address)
Patches end at 0x00209170 (RAM address)
Application starts at 0x0020905C (RAM address)
Application ends at 0x0020C3E4 (RAM address)
Patch size (including reused RAM) 14424 bytes
Patch size 14148 bytes
Application size 13192 bytes
------
Total RAM footprint 27340 bytes (26.7kiB)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content