![]() |
Coming soon |
1. STM32WB - BLE GATT DB SRAM computation
How to calculate CFG_BLE_NUM_GATT_ATTRIBUTES ? Defines the maximum number of attribute records related to all the required characteristics that can be stored in the GATT database, for the specific BLE user application
For each characteristic, the number of attribute records goes from two to five depending on the characteristic properties:
minimum of two (one for declaration and one for the value) add one more record for each additional property: notify or indicate, broadcast, extended property.
The total calculated value must be increased by 9, due to the records related to the standard attribute profile and GAP service characteristics, and automatically added when initializing GATT and GAP layers
Min value: <number of user attributes> + 9 Max value: depending on the GATT database defined by user application
How to calculate CFG_BLE_NUM_GATT_SERVICES ? Defines the maximum number of services that can be stored in the GATT database. Note that the GAP and GATT services are automatically added at initialization so this parameter must be the number of user services increased by two.
Min value: <number of user service> + 2 Max value: depending GATT database defined by user application
How to calculate CFG_BLE_ATT_VALUE_ARRAY_SIZE ? Defines the size of the storage area for the attribute values
Each characteristic contributes to the Attribute Value Array Size as follow: Characteristic value length plus: – 5 bytes if characteristic UUID is 16 bits – 19 bytes if characteristic UUID is 128 bits – 2 bytes if characteristic has a server configuration descriptor – 2 bytes * CFG_BLE_NUM_LINK if the characteristic has a client configuration descriptor – 2 bytes if the characteristic has extended properties Each descriptor contributes to the Attribute Value Array Size as follow: Descriptor length
Moreover, it is necessary to add characteristics related to the default GATT services.
For example: Service change characteristic (if not removed): 9 (5+2+2), 2 for indicate, 2 for number of link Device Name: 13 (5+2+6), 2 for broadcast, 6 for name length Appearance: 7 (5+2), 2 for attribute length Peripheral Preferred Connection Parameters: 13 (5+8), 8 for attribute length
2. STM32WB - BLE GATT DB and security record in NVM
The GATT record in NVM is composed per service
2 bytes for handle 3 or 17 bytes for UUID
per characteristic attribute
2 bytes for handle 3 or 17 bytes for UUID 2 bytes for CCCD value (only if the attribute is a CCCD)
The security record in NVM is fixed and equal to:
80 bytes
3. STM32WB - BLE number of bonded devices in NVM
Regarding the size of NVM, the computation of number of bonded devices that can be "theoretically" stored in NVM is the following:
n = (total_size_of_nvm-1) / [ (size_of_sec_record+1) + (size_of_gatt record+1) ]
Here:
total_size_of_nvm = 507 words (taken from M0 appli FW)
size_of_sec_record = 20 words (this is a constant from the BLE stack) size_of_gatt record = 36 words (depends on customer application: I take this number from the dump) where word equal 4 bytes
if we suppose that SECURITY and GATT records are both written, we find: n = 8
The GATT record is composed the following way:
per service
- 2 bytes for handle
- 3 or 17 bytes for UUID
per characteristic attribute
- 2 bytes for handle
- 3 or 17 bytes for UUID
- 2 bytes for CCCD value (only if the attribute is a CCCD)
3.1. Example 1
Default GATT configuration without adding services:
GATT record = 12 words 47 bytes for default
3.2. Example 2
Default GATT configuration + 1 empty service with UUID_16
GATT record = 13 words 47 bytes for default + 5 bytes for the service
3.3. Example 3
Default GATT configuration + 1 service with UUID_16 + 1 characteristic with UUID_16
GATT record = 18 words 47 bytes for default + 5 bytes for the service + 5 bytes for the 1st characteristic attribute + 5 bytes for the 2nd characteristic attribute + 7 bytes for the 3rd characteristic attribute (CCCD)
3.4. General information
We don’t store values of attributes, only the CCCD value.
it is applicable for GATT server.
On client side it is not at all used. On server side it is used to: - check if services have changed (which is useless for most of the applications, I guess. This could be optimized...) - keep CCCD in memory