• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1640 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2541 BLE stack heap usage and failure tolerance ?

Per Laursen
Prodigy 65 points
Other Parts Discussed in Thread: CC2541

Our peripheral application on the CC2541 is (as many others on the forum) stretching the RAM to its limits.

We have INT_HEAP_LEN=3290 (which leaves 6 unused bytes...), and that works ok for most uses. Every 50ms (triggered by the periodic event timer), we check for the number of failed allocations - we have instrumented OSAL_Memory.c for this. If the number of failed allocations is nonzero, we halt.

Recently, we've been extending the application to receive bulk data form the connected client. It seems that Low-ish rates work ok, but high rates cause a significant increase in heap use. The heap use of the application itself does not depend of the rate of incoming data.

So, two questions:

1: Can anyone confirm that heap usage increases with the rate of incoming data ?

2: Is the BLE stack tolerant to failed calls to osal_mem_alloc() - or can unpredictable behaviour be expected in case of failures ?

<rant>Access to the source code for the BLE stack would be REALLY nice...</rant>

BR

Per Laursen

  • 0
    Mastermind 8695 points

    There are 2 heaps. the first is defined by IAR in the project options. This heap uses the standard C functions malloc(), free(), etc.

    TI made their own heap in source code separate from this. You can see the source code for osal_mem_alloc(). They create a static variable called theHeap. The size of this heap is declared in source code by the macro MAXMEMHEAP. For the rest of this post "theHeap" refers to the TI heap, and "heap" refers to the built in heap by IAR.

    theHeap will fill up. When this happens, osal_mem_alloc() will return a null pointer. You need to check every pointer to see if its equal to NULL before using it. I'm unsure of what you mean by "failed calls". If your application is unable to call functions, then you'll need to fix many more things. 

    When you write to theHeap, a certain amount of memory is used alongside the data you are writing. For example, if you allocated space for 5 bytes, 7 bytes are actually used up. 

    Edit: The IAR heap I was referencing doesn't actually get included in the final executable if you never call malloc() or any of the other functions that use the heap. you can verify this be seeing if XDATA_HEAP has any space in the .map file

  • 0 in reply to Peter Borenstein
    Prodigy 200 points
    I think Per's question were quite clear. They are not answered yet, so I'll try to ask in more detail. If I understand right the OSAL heap is used by the BLE stack. How "robust" is the stack if the OSAL heap runs out of memory? Or, in other words, will the BLE stack check for NULL pointers and act properly? Regards, Ralf
  • 0
    TI__Mastermind 23440 points

    Hi Per,

    The BLE stack uses the heap to store e.g. writes and notifications that aren't processed. For higher throughput, more of the heap will be used after each connection event because more data has been received.

    If your application processes incoming data slower than it's received for whatever reason then you may end up with a full heap.

    The return from malloc is always checked, and if possible, gracefully handled. For incoming data, this shouldn't be a problem due to the flow control that exists on the MAC layer.

    BR,
    Aslak