• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 318 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.

BLE xdata reduction

Jerome Baron
Intellectual 810 points
Other Parts Discussed in Thread: CC2540

Hi everyone,

I'm trying to reduce as much as possible the utilization of the XDATA by the BLE stack. By looking at the .map file, I see 3 big objects:

OSAL_Memory ~3075B

ll ~918B

ll_scheduler ~1283B

I have already reduced OSAL_Memory to 591B, below that, I get warning during compilation, so I guess it will result in error during execution. Does anyone know how to reduce the two other module?

Best regards,

Jerome Baron

  • 0
    Genius 4125 points

    As far as I know there is no external control over the Link Layer memory allocation, so the only way to change this would be to get access to the stack source or write your own stack. Both of these options seem unlikely and would probably compromise the BLE operation. 

    I would guess that reducing the OSAL memory as much as you have would create some serious operation issues but I guess that all depends on what you are doing with the stack. 

    The question is what do you need the additional memory for? I too am running some fairly memory hungry applications and use the OSAL to allocate several large buffers for this with no problems. Are you able to use external SPI memory if this is not enough?

    I too have felt that the CC2540 could do with say 16KB SRAM as there isn't a huge amount left over once the stack and OSAL for BLE has taken its share.

  • 0 in reply to Eng351
    Intellectual 810 points

    Hi, thanks for your answer. My application is really memory consuming. I have an AT parser with a lot of command/answer with some big array that need to be in flash as well as a framebuffer for an external LCD.

    What do you mean by : "I would guess that reducing the OSAL memory as much as you have would create some serious operation issues but I guess that all depends on what you are doing with the stack. "

    There's still almost 600 bytes for the stack to use. I don't use any dynamic memory allocation in my application. Do you think the BLE stack needs more flash to work properly? There's no documentation regarding this.

  • 0 in reply to Jerome Baron
    Genius 4125 points

    It would depend on what type and how many of BLE connection(s) you are running. I really don't know how much heap the stack uses but this could be determined using osal_heap_block_free(). It is just a gut feel that reducing it to 1/5 of its original size could cause memory allocation issues. It would need to be tested carefully.

    I think you are confusing RAM with Flash above, Flash is program memory.

  • 0 in reply to Eng351
    Intellectual 810 points

    Thanks for the tip, I will monitor the osal_heap_block_free() to see if it comes neer to zero. My application doesn't use much bluetooth. Only one connection at the time and I only do RSSI monitoring.

    By default, with the 640 of stack as configured in the demo application, the SimpleBLECentral takes ~7kB. There's not much left for the application part!