Current Time Service Discovery Failing in First Connection After Reset

[ereksonr]

I have a device that runs NCS 2.0.2 on an nrf5340 and have an occasional issue with service discovery.

I have recently found that after calling sys_reboot() on my device, during the first BLE connection after the reboot my device will fail to discover the current time service on the Central device. Subsequent connections have no issue with discovering the service.

My initial call to bt_gatt_dm_start() ends in the "service_not_found" callback being called after a 30 second timeout. If I then re-attempt discovery, bt_gatt_dm_start() returns -12 (ENOMEM).

This appears to be linked to the configuration "CONFIG_BT_L2CAP_TX_BUF_COUNT". I tried doubling the number of buffers in my prj.conf, and still encounter this issue.

[Sigurd Hellesvik]

Hi,

I have recently found that after calling sys_reboot() on my device, during the first BLE connection after the reboot my device will fail to discover the current time service on the Central device. Subsequent connections have no issue with discovering the service.

How long is it between the reboot and the connection?
What happens if you delay the connection 10 seconds?

If I then re-attempt discovery, bt_gatt_dm_start() returns -12 (ENOMEM).

Are you able to debug the problem and find exactly the line showing "return ENOMEM"?

This appears to be linked to the configuration "CONFIG_BT_L2CAP_TX_BUF_COUNT".

How do these appear to be linked?

Regards,
Sigurd Hellesvik

[ereksonr]

Hi Sigurd,

Sigurd Hellesvik said:

How long is it between the reboot and the connection?

It is about 1 minute from the reboot until a connection is attempted.

Sigurd Hellesvik said:

What happens if you delay the connection 10 seconds?

Varying timing does not seem to have an effect. I have waited as long as 2 minutes before beginning advertisements to establish the connection

Sigurd Hellesvik said:

Are you able to debug the problem and find exactly the line showing "return ENOMEM"?

ENOMEM appears to be coming from line 2264 of gatt.c:

req = gatt_req_alloc(func, params, encode, op, len);

if (!req) {

    return -ENOMEM;

}

If I trace this down further, it appears to be a call to k_mem_slab_alloc() on line 3428 of att.c that times out, causing the error.

Sigurd Hellesvik said:

This appears to be linked to the configuration "CONFIG_BT_L2CAP_TX_BUF_COUNT".

How do these appear to be linked?

the k_mem_slab_alloc() call is allocating space from "req_slab", the size of which is defined by 

CONFIG_BT_L2CAP_TX_BUF_COUNT

[Sigurd Hellesvik]

Try to increase CONFIG_BT_RX_STACK_SIZE, for example to 4096

Does that help?

[ereksonr]

I was able to test this out today. Unfortunately it does not fix the issue

[Sigurd Hellesvik]

That is odd. Let's have a closer look at the communicaiton and see if we can understand what goes wrong.

 Can you capture a sniffer log and upload it here as a pcap file using Insert -> Image/video/file? See Bluetooth Low Energy nRF Sniffer for Bluetooth LE for how to set up and use our Bluetooth Low Energy sniffer.