Dynamically Allocated GATT Service Not Visible in nRF Connect for mobile

[Mahmoud Fadel]

When dynamically allocating BLE GATT services and characteristics using custom structures and Zephyr’s dynamic memory functions (e.g., k_malloc, k_calloc), the service registration using bt_gatt_service_register function reports success and the internal GATT database enumeration (via bt_gatt_foreach_attr) shows all attributes with correct UUIDs and permissions. However, the dynamically allocated service does not appear in external BLE scanning tools (e.g., nRF Connect for mobile).
Additional Notes:
The issue does not occur with statically defined services (using BT_GATT_SERVICE_DEFINE), but I'm asking about dynamic allocation and if there any example show steps of dynamic service allocation

[MarkLaloo]

Hi,

I've run into the same issue, NCS v2.9.0, nRF54L15. 

Initially, I defined my attribute structs statically, which works as expected.

I'm now trying to do something similar to Mahmoud; dynamic allocation. bt_gatt_service_register shows no error (err = 0), though I am unable to see the services in nRF Connect.

To sanity check, I passed the static defined attrs variable into my service and this works; so there is definitely something missing in how the bt_gatt_attr structs are being defined or configured.

Is there any sample that displays this approach? Thus far, I've only come across samples with statically defined Attributes and Services.

* Generic Attribute and Generic Access contents show no change regardless of bt_gatt_service_register being called with dynamic attributes, CONFIG_BT_GATT_DYNAMIC_DB is enabled, as well as CONFIG_BT_GATT_SERVICE_CHANGED. I've also referenced this Ticket, CONFIG_SETTINGS=y made no difference. I've also confirmed toggling BT on the phone changes nothing, force refresh of services also does nothing, and no Bond information to delete.

Thanks in advance!

Kind regards,
Mark Laloo

[MarkLaloo]

Hi,

Stumbled across this ticket, which helped solve the issue (see sample in the Answer response)

Kind regards,
Mark Laloo