• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 1637 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.

cc2540 memory issue

Omri Berg1
Intellectual 1000 points

Hey TI experts,

I have a little memory issue and I was hoping you could share some light on the subject.

As I'm trying to allocate memory on the stack in my code, I'm able to build the code buy when running it gets stuck with no error, when I step in one line at a time, I'm getting the warnning :

" The stack pointer for stack 'XdataStack' (currently XData:0xFFFF) is outside the stack range (XData:0x0001 to XData:0x0281)"

-I've changed the heap size to 1000 in the project properties. (which let me allocate a little bit more but still not enough)

-Looking at the map file shows this:

114 619 bytes of CODE memory
35 bytes of DATA memory (+ 77 absolute )
4 180 bytes of XDATA memory
194 bytes of IDATA memory
8 bits of BIT memory
4 142 bytes of CONST memory

which seems ok

If I'm trying to allocate less memory it works fine.

Thanks in advance.

  • 0
    Intellectual 805 points

    It looks like you have two mistakes:

    1. The TI BLE sample apps do not use the IAR library heap manager, so you should not be changing the project setting of heap size to get more heap. There is an OSAL heap manager and it is configured with this constant:

    INT_HEAP_LEN=3072

    In the simple peripheral, you can bump it to 4800 and still fit.

    2. Your c-code call stack wrapping (blowing the stack) is evidence that you are using huge automatic variables and/or using recursion that goes too deep or is infinite. Reduce the call-stack used by huge local variables by making them pointers and osal_mem_alloc() the space for the huge automatic variables instead.

  • 0 in reply to codesmith
    Intellectual 1000 points

    Thanks for the replay.

    - The meaning in my first post is that I changed INT_HEAP_LEN to 1000

    - I'm allocating the space needed for the db as automatic variable, this is a temp db which, when gets full, is copied to the flash memory. still I would like to have it bigger then it is now.

    why would it be better to place it on the heap instead? 

  • 0 in reply to Omri Berg1
    Intellectual 805 points

    Omri - your horrible experience with the silent failure of a blown C call-stack begs the answer to your question as to why to use heap memory instead of huge automatic variables: using osal_mem_alloc() returns a failure code so you explicitly know whether or not there is enough space to do what you want to do exactly when you want to do it. Whereas just assuming the space is available with huge automatic variables fails silently and non-deterministically with a blown stack and a nightmare trying to debug or diagnose it.