Memory size limits on 20732?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

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?

0 Likes
1 Solution
Anonymous
Not applicable

Hello idgirod,

(1) What is the maximum code size and how can I tell whether I am reaching it?

[JT] -

(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

  1. Disabling battery monitor will not give you more space because its in the ROM.
  2. The next version of our chip will enable some of these features.

Notes:

  1. The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.
  2. 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.
  3. 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:

Mem_Map_1.PNG

  1. The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.
  2. Note that our Stack (YELLOW) is 30K and is DATA ONLY.
  3. The Patches Section (Features,Updates, etc) is combined with the User App but:
    1. The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded.
    2. 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:

Mem_Map_2.PNG

And finally, we can see the Overlap in the code:

Mem_Map_3.PNG

Hopefully this gets you started.

JT

View solution in original post

6 Replies
Anonymous
Not applicable

Hello idgirod,

(1) What is the maximum code size and how can I tell whether I am reaching it?

[JT] -

(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

  1. Disabling battery monitor will not give you more space because its in the ROM.
  2. The next version of our chip will enable some of these features.

Notes:

  1. The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.
  2. 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.
  3. 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:

Mem_Map_1.PNG

  1. The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.
  2. Note that our Stack (YELLOW) is 30K and is DATA ONLY.
  3. The Patches Section (Features,Updates, etc) is combined with the User App but:
    1. The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded.
    2. 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:

Mem_Map_2.PNG

And finally, we can see the Overlap in the code:

Mem_Map_3.PNG

Hopefully this gets you started.

JT

thank you, this is super helpful!

0 Likes

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!!!

0 Likes
Anonymous
Not applicable

Hello idgirod,

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. Initialized globals have to have some value before the app initializes.
  2. 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.
  3. 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

0 Likes
Anonymous
Not applicable

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)

0 Likes

Take a look at this thread as I believe it answers your question: Stack overruns and max stack size

0 Likes