CC2541: Understanding Heap memory usage

Hey Varun,

As you have discovered, it sounds like you are short of heap memory. I would recommend profiling the usage to determine how much you need to save to ensure proper function of your application. Unfortunately it's difficult to give you an exact answer for minimum allocated memory as it depends highly on the application.

To monitor the heap, you can navigate to the Software Developer's Guide located in the SDK_INSTALL_DIR>Documents>TI_BLE_Software_Developer's_Guide.pdf. In particular, navigate to Section 3.4 Heap Manager. You will have to set a preprocessor symbol and reflash the project to enable this.

Hi Ammar,

Thank you for your reply.

I checked the variable memMax and while running, the value it held was 1840 bytes - 2200 bytes and in our system, we allocated #define INT_HEAP_LEN 3072 for heap.

1. I presume this implies the memory we allocated is sufficient? Please correct me if I am wrong.

However, when I was reviewing the map file and calculated OSAL related xdata memory , it is 3113 bytes (3+2+ 10 + 3085 +7 +6). 

2. Does this mean do I need to allocate additional 43 bytes (3113 - 3072 ) for INT_HEAP_LEN ?

OSAL                       1 481                    3
OSAL_BcpApplication          145                    2                          29
OSAL_ClockBLE                255                   10
OSAL_Memory                  744                3 085
OSAL_PwrMgr                  183                    7
OSAL_Timers                1 217                    6

Best,

Varun

(Sorry I click on the orange button, it was not meant - I will keep handling the thread anyway)

Hi Varun,

The statically allocated memory (like the OSAL memory) is not supposed to be accounted for in the heap.

Make sure to take the value of memMax  in the worst case.

The memory stack size might also be the cause of your issue. Without tools, it might be difficult to identify such an issue. So I would recommend to run some tests where you increase it and see if it helps.

Best regards,

Hi Clement,

Sorry, I thought OSAL memory goes to Heap (The memory set aside for the heap shows up in the map file under the OSAL_Memory module -as per the SW develeopers guide).

The memory stack size might also be the cause of your issue. Without tools, it might be difficult to identify such an issue. So I would recommend to run some tests where you increase it and see if it helps.

--> Just to confirm, by increasing the value of INT_HEAP_LEN , right?

Best,

Varun

Hi,

Varun Sasindran said:

The memory stack size might also be the cause of your issue. Without tools, it might be difficult to identify such an issue. So I would recommend to run some tests where you increase it and see if it helps.

--> Just to confirm, by increasing the value of INT_HEAP_LEN , right?

Actually this suggestion was not correct for CC2541. Stack overflow is fairly unlikely in a 8051 because the stack is not used very heavily. Without effective indirect addressing modes it is mostly restricted to holding return addresses (managed automatically by the MCU) and saved registers (mostly in ISRs).

Hi Clement, 

the system goes very un predictable. It don't remember the bonding sometimes. Sometimes it wont bond and as a result it goes undiscoverable. I added this code in a periodic task to make sure the system will keep advertising  every minute if not connected so that it is discoverable by the other devices. But still it don't work.

if(gapRole_state != GAPROLE_CONNECTED && gapRole_state != GAPROLE_CONNECTED_ADV)
      {
        periph_mode = osal_start_timerEx( gapRole_TaskID, START_ADVERTISING_EVT, 1 ); 
      }

Best,

Varurn

While testing today, I noticed duplicate entries of blueto0th device address in NV ram

This is what I store in the FD01 charactersitics:

    uint8* ptr1                   = GAPBondMgr_GetBondedAddress(0);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[1U],ptr1,B_ADDR_LEN);
    ptr1                          = GAPBondMgr_GetBondedAddress(1);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[7U],ptr1,B_ADDR_LEN);
    ptr1                          = GAPBondMgr_GetBondedAddress(2);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[13U],ptr1,B_ADDR_LEN);

Using the latest BLE Stack 1.5.2.0

Is there a reason it is storing a duplicate entry in NV ram?

Best,

Varun

Hi Varun,

I am not familiar with the function GAPBondMgr_GetBondedAddress().

It would be interesting to see if this function basically reports the content of the memory - even if the bonds has been invalidated - or if it reports only the valid bonds.

In all the cases, the gap bond manager should not store more than GAP_BONDINGS_MAX bonds in Flash (see here). In addition, the gap bond manager is not supposed to create a bond (rather to update it) if a bond already exist for a device with the same public address.

I hope this will help,

Best regards,

Hi Clement,

Sorry, the function takes value from bonds[index].publicAddr ;

Best,

Varun

Hi Varun,

When a bond is erased from the Flash, the RAM is updated right after. So this issue should not occur.

Given the RAM issue you are experiencing, there maybe some memory allocation not possible resulting in problems to overwrite (with 0xFF) the bond in Flash. As a consequence, the bonds are not properly erased and the system gets in an incorrect state.

I hope this will help,

Best regards,