This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: Program not runnable when SRAM consumption ~90%

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Hello there,

I'm currently experiencing a strange behaviour regarding SRAM usage. The problem is reproducable, the steps are the following:

1) Open up simple_broadcaster_cc2640r2lp_app and compile it, Memory Allocation should show SRAM consumption of 38%. The program is running fine.

2) Open simple_broadcaster.c and increase the task's stack size to 10000 (SBB_TASK_STACK_SIZE) and compile it, Memory Allocation should show SRAM consumption of 91% (so nearly 2.5kB of free SRAM still left). The program is not running/advertising anymore.

3) Decrease the task's stack size to say 9000 and the program is running again.

Could you tell me what's the cause of this behaviour? Is the remaining SRAM not enough for the heap?

Thanks in advance,

Philipp

  • Hi Philipp,

    It is indeed the heap that's throwing an error. From what I can understand is that by default the Heap Manager is configured to be auto sized, that is the remaining RAM (not used by the system) will be fully assign to the Heap).

    In your case, when you set the SBB_TASK_STACK_SIZE to 10000, around 1k of RAM is left for the Heap. This causes some immediate issues at startup when ICall is initializing its tasks which allocates stacks on the heap. Now, when you decrease SBB_TASK_STACK_SIZE to 9000, you suddenly have enough Heap to allocate the ICall stacks, which makes the application run again.

    What you can do is to configure the Heap Manager to be fixed sized. This at least guarantees that your application will always have a minimum Heap size which you know is required.

    I recommend reading up on how to debug common heap issues from the BLE-stack User's Guide: dev.ti.com/.../ble-index.html
  • Thank you very much Edvard! :-)

    Regards,
    Philipp