Unable to connect after setting CONFIG_BT_DEVICE_NAME_DYNAMIC=y

[Dane du Plooy]

After setting the 

CONFIG_BT_DEVICE_NAME_DYNAMIC=y

option I am unable to connect to the device anymore from the nRF Connect app (or others), even after removing that option again. The app connects, but then immediately disconnects again with reason 0x2A (BT_HCI_ERR_DIFF_TRANS_COLLISION). I have tried from two Android devices so far.

This is very probably more of an Android issue than an nRF issue, but I was hoping that someone on this forum may nonetheless have some advice regarding this issue.

In Android, I have tried:

- Clearing BlueTooth cache and data

- Clearing nRF Connect app cache and data

- Resetting network settings

- Restarting

(basically everything short of factory reset).

Any ideas?

[Einar Thorsrud]

Hi,

I tested this with the CGMS sample from nRF Connect SDK 2.7.0 where I only addded CONFIG_BT_DEVICE_NAME_DYNAMIC=y and a Samsung Galaxy S23+ with Android 14, but was not able to reproduce it. Are you able to reproduce this with a sample application with this change, or are other changes needed? If so which, or do you have an application you can share?

Also, which phon emodels and Android versions did you reproduce this with, and have you tested with other devices that did work?

[Dane du Plooy]

Hi Einar

Thank-you for testing this.

Today when I have tested then the problem seems to be much more intermittent (yesterday I could reliably reproduce it).

Today it is only occurring when I try use my service definition. Can you see anything wrong with the below?

#define BT_UUID_BEACON_SERVICE_VAL 				BT_UUID_128_ENCODE(0x00001523, 0x1212, 0xefde, 0x1523, 0x785feabcd123)
#define BT_UUID_BEACON_TYPE_CHARACTERISTIC_VAL	BT_UUID_128_ENCODE(0x00001524, 0x1212, 0xefde, 0x1523, 0x785feabcd123)

#define BT_UUID_BEACON_SERVICE 					BT_UUID_DECLARE_128(BT_UUID_BEACON_SERVICE_VAL)
#define BT_UUID_BEACON_TYPE_CHARACTERISTIC 		BT_UUID_DECLARE_128(BT_UUID_BEACON_TYPE_CHARACTERISTIC_VAL)

typedef enum {
	BeaconType_Eddystone_TLM = 1,
	BeaconType_Eddystone_UID = 2,
	BeaconType_iBeacon = 3,
} BeaconType;

static uint8_t mBeaconType = BeaconType_Eddystone_TLM;

static ssize_t ble_chrc_type_read(struct bt_conn *conn, const struct bt_gatt_attr *attr, void *buf,
			   uint16_t len, uint16_t offset) {
	// Get a pointer to mBeaconType which is passed in the BT_GATT_CHARACTERISTIC() and stored in attr->user_data
	const char *value = attr->user_data;
	return bt_gatt_attr_read(conn, attr, buf, len, offset, value, sizeof(*value));
}

BT_GATT_SERVICE_DEFINE(mBeaconService, 
	BT_GATT_PRIMARY_SERVICE(BT_UUID_BEACON_SERVICE),
	BT_GATT_CHARACTERISTIC(BT_UUID_BEACON_TYPE_CHARACTERISTIC, BT_GATT_CHRC_READ,
				BT_GATT_PERM_READ, ble_chrc_type_read, NULL, &mBeaconType),		  
);

[Einar Thorsrud]

Hi,

I do not see an obvious issue with this code snippet. Did you resovle this? Or are you able to share a failing example that I can run on a DK?

[Dane du Plooy]

After a lot of experimenting, trying example projects and stripped-down versions of my own project, it is now working. My best guess at this stage is that trying the example programs which have the same UUID but different parameters (bt_le_adv_param) resets something in Android. I would find that BT_GATT_CHRC_READ would not work, then I would get it working in another sample or stripped-down version of my project, and then coming back to my project without changing anything it would then work. Same for BT_GATT_CHRC_WRITE, and then BT_GATT_CHRC_READ | BT_GATT_CHRC_WRITE. Very tedious problem-finding process, but at least it seems to be working now.