Optimization

Optimizing Bluetooth Low Energy Stack Memory Usage

Configuration of the Bluetooth Low Energy protocol stack is essential for maximizing the amount of RAM and flash memory available for the application. Refer to Stack Configurations to configure parameters that impact runtime RAM usage, such as the maximum allowable size and number of PDUs. The TI Bluetooth Low Energy protocol stack is implemented to use a small RAM footprint, and allow the application to control the behavior of the stack by using the runtime ICall heap. For example, an application that only sends one GATT notification per connection event must store only one PDU in the heap, whereas as an application that must send multiple notifications must enqueue multiple PDUs in the heap.

To increase the available flash memory allocated to the application project, minimize the flash usage of the protocol stack by including only Bluetooth Low Energy features required to implement the defined role of the device. The available protocol stack configurable features are described in Stack Configurations. Adding additional features to the protocol stack has the net effect of reducing the amount of flash memory to the application.

Flash optimization

The following tips may be useful for reducing the footprint of the BLE5-Stack. In general, there is a feature vs. flash footprint trade-off. Each of the improvements below offer a cost in terms of feature removal.

  • Verify that your application uses the optimize for flash size compiler optimization settings (For TIClang it is implemented with the -z flag).

  • Use only one page of SNV option under the Advanced Settings of the BLE stack in the syscfg file.

  • Remove or exclude the Menu Module (located in the Common folder) or other unused drivers from your project.

  • Use the syscfg file to choose only necessary functionality to pull in the smallest part possible of the library for the given use case. In general, this means a library that implements only one role (e.g. peripheral) with no additional features enabled (i.e. L2CAP CoC). See Stack Configurations.

  • Remove HAL Asserts by unchecking the HAL_ASSERT option under the advanced settings of the BLE stack in the syscfg file.

RAM optimization

The following tips may be useful for reducing the RAM footprint of the BLE5-Stack. It is important to remember that often removing RAM results in reduced throughput or features, the tradeoffs listed below should be evaluated carefully.

  • Set MAX_NUM_PDU and MAX_PDU_SIZE to reduce the amount of packets that can be queued up by the stack at a time. This will reduce heap consumption with the tradeoff of bandwidth. They can be set under the General Configuration of the BLE stack in the syscfg file.

  • The LE Data Length Extension feature will default to an RX size of 251. If the peer device also supports DLE and a connMaxRxOctets value is negotiated > 27 (default) then the controller will allocate connMaxRxOctets*4. 4 is the number of receive buffers in the controller and is a fixed parameter of the stack. However, connMaxRxOctets can be limited by either disabling Data Length Extension or limiting the max of TX and RX octets. Trimming the values of TX and RX is covered in RAM Considerations when using DLE.

  • Carefully set MAX_NUM_BLE_CONNS under the General Configuration section of the BLE stack in the syscfg file. This define has a large effect on the amount of dynamic memory used by the stack. Below are examples of structures that the stack will allocate on initialization based on number of Connections. Each structure is multiplied by MAX_NUM_BLE_CONNS

    • rxDataQ_t : Each connection’s receive queue

    • rxDataQ_t : Each connection’s receive queue

    • RCL_CmdBle5Connection : Command to run connection event as central or peripheral

    • RCL_CtxConnection : Context for a connection

  • The BLE5-Stack uses FreeRTOS heap_4 module for its memory allocation, refer to Debugging Common Heap Issues for more information on how to control and view the heap.

Warning

The above RAM estimations may vary by release, and are not an exhaustive list. It is intended as a way to allow the developer to profile the RAM requirements based on the desired settings. The best way to estimate RAM usage is to measure it in the field using the techniques covered in Debugging Common Heap Issues

Heap and Stack sizing

The Heap does not auto-scale and will need to be set under the Stack and Heap sizing section under the FreeRTOS tab in the Syscfg file.

The following steps show how to maximize the heap memory (in order to use all the RAM available on the device):

  • Build the project and go to .map file

  • Check Unused SRAM section at the top of the .map file

    ../_images/check_ram_usage_map_file.png

  • In the FREERTOS section of the .syscfg file, go to the Stack and Heap sizing section.

  • Increase the Heap size value based on the amount of SRAM left unused previously. Due to memory alignment constraint you will likely not be able to allocate all the available RAM.

    ../_images/change_heap_size_freertos_sysconfig.png

The ROV can be leveraged when running the program with the debugger attached to observe the heap used after device boots, this will indicate the real amount of memory the application has left to run.

See Check System Flash and RAM Usage With Map File for the procedure to check the size of the configured protocol stack.