1.1.1.3.3 BLE Memory Usage for PIC32CX-BZ6

The application framework is an essential structure for application development, offering a suite of predefined functionalities and libraries that streamline the creation process. When developing a BLE application, certain components are necessary, especially for the PIC32CX-BZ6 H3 family of devices. These components include Device Support, Core, FreeRTOS, Persistent Data Storage (PDS), and Non-Volatile Memory (NVM). For the PIC32CX-BZ6 H3 family, additional specific components are required: EVSYS, Device Family Pack and System Component.

By utilizing these components, developers can efficiently build robust and feature-rich BLE applications tailored to the PIC32CX-BZ6 H3 family.

The BLE stack is a critical component in wireless communication, but it can also be a substantial memory consumer. To optimize memory usage, it's crucial to assess the stack size requirements, which vary depending on the specific features enabled within the stack. Selecting the appropriate BLE stack mode and configuring it to include only the necessary features are key steps in managing memory consumption effectively in BLE-enabled devices.

1. BLE Stack

   There are two primary modes of operation for the BLE stack: full stack and HCI mode. In full stack mode, the features are highly configurable, allowing developers to tailor the stack to meet the precise needs of their application, potentially reducing the memory footprint by disabling unnecessary features. On the other hand, HCI mode provides a comprehensive set of BLE controller capabilities without the need for manual configuration.

   • Full Stack Mode

     The BLE stack is responsible for implementing the Bluetooth protocol stack necessary for BLE communication. It typically consists of several layers, including the Physical Layer (PHY), Link Layer, Logical Link Control and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic Attribute Profile (GATT), and Generic Access Profile (GAP). The BLE stack abstracts low-level Bluetooth operations, providing APIs for higher-level application layers to manage BLE connections, advertisements, data exchange, and security. The BLE stack is designed in a modularized fashion, with proper configuration, the BLE memory usage can be very efficient. The module unit is based on the GAP role; however, there is some common code shared between modules, so the overall memory consumption is not stacked.

   • HCI Mode

     The BLE stack in HCI mode functions at the Host Controller Interface (HCI) layer. This mode ensures that the BLE stack communicates with the Bluetooth controller solely via HCI commands and events, effectively encapsulating the complexities of the lower-level Bluetooth protocol stack. By operating in HCI mode, the BLE stack provides comprehensive support for the entire range of BLE controller features. However, it is important to note that in this mode, program memory usage is fixed and cannot be modified or optimized by the user.

   Table 1-12. BLE stack memory footprint

   BLE Stack (byte)		Static Data Memory	Dynamic Data Memory	Program Memory
   Full Stack Mode	Adv / Peripheral	2.5K	8.3K (Only one BLE connection condition is included) + TX_BUFFER_SIZE	127K
   	Scan / Central	2.1K	7.6K (Only one BLE connection condition is included) + TX_BUFFER_SIZE	128K
   	Adv / Peripheral / Scan / Central	2.7K	9.1K (Only one BLE connection condition is included) + TX_BUFFER_SIZE	144K
   HCI Mode		2.5K	7.9K (Only one BLE connection condition is included) + TX_BUFFER_SIZE	152K

   ** Optimizing the TX_BUFFER_SIZE: When BLE Application calls the relevant API to send data, BLE Stack allocates memory for each TX packet and places it into a transmission queue. Once the packet is ready, BLE Stack retrieves it from the queue and transmits it over the air. After successful transmission, BLE Stack frees the memory previously allocated for that packet, ensuring efficient memory usage. However, there are limitations to this memory allocation process. The total number of TX packets that can be queued across all connections is capped at 24. For each individual connection, the maximum number of queued TX packets is dynamically calculated as 24 divided by the current number of active connections. Consequently, the maximum allocated memory per connection is determined by multiplying the number of queued TX packets by 256 bytes. For example, with one active connection, the system can queue up to 24 TX packets, resulting in a maximum allocated memory of 24 * 256 = 6144 bytes. In practice, the actual memory usage is often lower, as only a few TX packets are typically allocated and waiting in the queue at any given time. This approach ensures that memory is efficiently managed.

   ** A single BLE connection necessitates 0.8 KB of data memory for Full Stack mode and 0.6KB for HCI mode. If the BLE application requires a multi-link scenario, additional data memory must be allocated for the BLE stack.

   To cater to the diverse needs of various applications, the BLE stack offers a suite of optional features that can be fine-tuned by users. Below is an overview of these configurable optional features:

   • Extended Advertising
   • Extended Scan
   • Periodic Advertising
   • Periodic Sync
   • Extended Central
   • GATT Client (Not applicable to HCI mode; it is only valid in the full stack mode)
   • L2CAP COC (Not applicable to HCI mode; it is only valid in the full stack mode)

   Optional features memory footprint

   • Extended Advertising
     • Program Memory: 14K bytes (Not applicable to HCI mode, as the cost is already included in the HCI mode program memory)
     • Dynamic Data Memory: The basic memory requirement is 0.4K bytes; however, additional memory may be necessary to accommodate advertising data of varying lengths.

     Advertising Data Length(byte)	Additional Memory(byte)
     1-31	0
     32-1650	(Advertising Data Length-31)*2.5

   • Extended Scan
     • Program Memory: 10K bytes (Not applicable to HCI mode, as the cost is already included in the HCI mode program memory)
     • Dynamic Data Memory: The basic memory requirement is 1.3K bytes; however, additional memory may be necessary to handle variable-length advertising data.

     Advertising Data Length(byte)	Additional Memory(byte)
     1-74	0
     75-1650	(Advertising Data Length-74)*2

   • Periodic Advertising
     • Program Memory: 5K bytes (Not applicable to HCI mode, as the cost is already included in the HCI mode program memory)
     • Dynamic Data Memory: The basic memory requirement is 0.2K bytes; however, additional memory may be necessary to accommodate advertising data of varying lengths.

     Periodic Advertising Data Length(byte)	Additional Memory(byte)
     1-31	0
     32-1650	(Periodic Advertising Data Length-31)*2.5

   • Periodic Sync
     • Program Memory: 8K bytes (Not applicable to HCI mode, as the cost is already included in the HCI mode program memory)
     • Static Data Memory: 0.1K bytes
     • Dynamic Data Memory: The basic memory requirement is 0.5K bytes; however, additional memory may be necessary to handle variable-length advertising data.

     Advertising Data Length(byte)	Additional Memory(byte)
     1-1650	(Advertising Data Length)*2.5

   • Extended Central
     • Program Memory: 3K bytes (Not applicable to HCI mode, as the cost is already included in the HCI mode program memory)
   • GATT Client
     • Program Memory: 5K bytes
   • L2CAP COC
     • Program Memory: 4K bytes
     • Dynamic Data Memory: 0.15K bytes plus 0.05K bytes for each additional connection.
2. BLE Middleware

   BLE Middleware sits between the application layer and the BLE stack. It provides additional functionality and abstraction to simplify the development of BLE applications. Middleware may include modules for managing device discovery, connection establishment, and security protocols. The BLE Middleware abstracts complex BLE operations, enabling developers to focus on application logic rather than low-level Bluetooth protocol details. Each submodule in BLE middleware is configurable and removable. The table below shows the valid condition for the submodule usage.

   GAP Role	Adv / Peripheral	Scan / Central	Adv / Peripheral / Scan / Central
   Submodule
   Device manager	V	V	V
   Database Discovery	V (If GATT Client supported)	V (If GATT Client supported)	V (If GATT Client supported)
   Service Change Manager	V	V	V
   Log	V	V	V

   Table 1-13. BLE middleware memory footprint

   BLE Middleware(byte)	Static Data Memory	Program Memory
   Device manager	0.2K	5K
   Database Discovery	< 10	3K
   Service Change Manager	< 100	2K
   AES	0	1K
   DFU	< 100	2K
   Log	< 10	8K

3. BLE Profile

   A BLE Profile defines a set of protocols tailored to a specific use case or application. Profiles streamline the development of BLE applications by providing a common framework for defining device functionality and communication protocols. Each BLE profile is a standalone unit, and users can determine whether the BLE profile is required or not.

   Table 1-14. BLE profile memory footprint

   BLE Profile(byte)	Static Data Memory	Program Memory
   ANCS (Alert Notification Center Service)	2.2K	2.8K
   ANPC (Alert Notification Profile - Client)	0.5K	1.8K
   ANPS (Alert Notification Profile - Server)	0.1K	1K
   HOGPS (HID over GATT Profile - HID Device)	0.1K	1.5K
   OTAPC (Over the Air Profile - Client)	0.5K	2.5K
   OTAPS (Over the Air Profile - Server)	0.2K	3K
   PXPM (Proximity Profile - Monitor)	0.5K	2K
   PXPR (Proximity Profile - Reporter)	0.1K	0.6K
   TRCBPS (Transparent Credit Based Profile - Server)	0.8K	2.5K
   TRSPC (Transparent Profile - Client)	1.5K	3K
   TRSPS (Transparent Profile - Server)	1.2K	2K

4. BLE Service

   A BLE Service is a collection of related characteristics that define a specific functionality or feature of a BLE device. Services are organized hierarchically within the GATT (Generic Attribute Profile) structure and are identified by unique UUIDs (Universally Unique Identifiers). Each service is a standalone unit, and developer can determine whether the BLE service is required or not.

   Table 1-15. BLE service memory footprint

   BLE Service(byte)	Static Data Memory	Program Memory
   ANS (Alert Notification Service)	0.2K	0.1K
   BAS (Battery Service)	0.1K	0.1K
   DIS (Device Information Service)	0.5K	1K
   HIDS (Human Interface Device Service)	0.6K	1.5K
   IAS (Immediate Alert Service)	0.1K	0.1K
   LLS (Link Loss Service)	0.1K	0.1K
   OTAS (Over the Air Service)	0.2K	0.2K
   TPS (TX Power Service)	0.1K	0.1K
   TRCBS (Transparent Credit Based Service)	0.2K	0.1K
   TRS (Transparent Service)	0.2K	0.1K