[NUS - Peripheral & Central] error of Set security : -12

[seongmincho]

I am programming BLE with the nRF52840-DK. [Toolchain Manager: v1.3.0, IDE: Visual Studio Code (VSCode), SDK: ncs v2.6.0, window11 pro]

My issue is that even when using the same 'NUS_central' code, the results of set_security and pairing vary depending on the hardware (nRF52840 DK).

[The command used is as follows: err = bt_conn_set_security(conn, BT_SECURITY_L2);"]

There are 3 case:

1. 'Pairing' success, 'set_security' success (I couldn't save the debugging results.)
2. 'Pairing' failure, 'set_security' success
3. 'Pairing' failure, 'set_security' failure

The problem with the third scenario is that NUS doesn't function properly. Could you advise on the cause and potential solutions for this?

<case2, bluetooth working O: below is log debugging Regarding nRF52840-dK1 >

[00:00:09.425,018] <inf> cho: <<< scan_connecting >>>>
[00:00:09.522,491] <inf> cho: connected - Set_Security >>> err:0
[00:00:09.529,388] <inf> cho: connected - bt_conn_le_param_update (err 0)
[00:00:09.536,865] <inf> cho: connected - PHY >>> err:0
[00:00:09.542,755] <inf> cho: connected - data_length >>> err:0
[00:00:09.549,041] <inf> cho: connected - SCAN_STOP (err -120)
[00:00:09.555,297] <inf> cho: connected - GET_INFO >>> err:0
[00:00:09.561,370] <inf> cho: connected - Conn. interval is 40 units
[00:00:09.673,797] <err> bt_smp: pairing failed (peer reason 0x3)
[00:00:09.680,633] <inf> cho: CALLBACK - Security change failed: 4
[00:00:09.687,286] <inf> cho: gatt_discover - GATT_dm_start: 0
[00:00:09.693,572] <inf> cho: CALLBACK - Pairing failed conn: E0:2D:55:2C:95:E1 (random), reason 4
[00:00:09.874,114] <inf> cho: CALLBACK - Connection parameters updated. >> interval: 48, latency: 0, timeout: 400
[00:00:10.163,787] <inf> cho: CALLBACK - LE data len updated: TX (len: 251 time: 2120) RX (len: 251 time: 2120)
[00:00:10.763,214] <inf> cho: CALLBACK - LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
[00:00:10.771,606] <inf> cho: CALLBACK - Service discovery completed
[00:00:10.778,533] <inf> cho: discovery_complete - MTU exchange pending
[00:00:11.003,662] <inf> cho: CALLBACK - MTU exchange done

<case3, bluetooth working X: below is log debugging Regarding nRF52840-dK2 > 

[00:00:04.812,042] <inf> cho: main - scan_init>> 0
[00:00:04.817,199] <inf> cho: bt_nus_client_init >>> err:0
[00:00:04.823,120] <inf> cho: main - nus_client_init>> 0
[00:00:04.829,833] <inf> cho: main - bt_scan_start>> 0
[00:00:04.897,552] <inf> cho: Filters matched. Address: E0:2D:55:2C:95:E1 (random) connectable: 0 
[00:00:04.908,508] <inf> cho: <<< scan_connecting >>>>
[00:00:05.000,091] <inf> cho: connected - Set_Security >>> err:-12
[00:00:05.007,049] <inf> cho: connected - bt_conn_le_param_update (err 0)
[00:00:05.014,526] <inf> cho: connected - PHY >>> err:0
[00:00:05.020,416] <inf> cho: connected - data_length >>> err:0
[00:00:05.026,702] <inf> cho: connected - SCAN_STOP (err -120)
[00:00:05.032,958] <inf> cho: connected - GET_INFO >>> err:0
[00:00:05.039,031] <inf> cho: connected - Conn. interval is 40 units
[00:00:05.351,531] <inf> cho: CALLBACK - Connection parameters updated. >> interval: 48, latency: 0, timeout: 400
[00:00:05.641,601] <inf> cho: CALLBACK - LE data len updated: TX (len: 251 time: 2120) RX (len: 251 time: 2120)
[00:00:06.241,027] <inf> cho: CALLBACK - LE PHY updated: TX PHY LE 2M, RX PHY LE 2M

below is connected callback function code:

static void connected(struct bt_conn *conn, uint8_t conn_err){
	char addr[BT_ADDR_LE_STR_LEN];
	int err;
	struct bt_conn_info info = {0};
	
	bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
	if(conn_err){
		LOG_INF("Failed to connect to %s (%d)", addr, conn_err);
		if (default_conn == conn) {
			bt_conn_unref(default_conn);
			default_conn = NULL;
			err = bt_scan_start(BT_SCAN_TYPE_SCAN_ACTIVE);
			LOG_INF("Scanning failed to start (err %d)",err);
		}
		return;
	}
	default_conn = bt_conn_ref(conn);
	// err = bt_conn_get_info(conn, &info);
	// LOG_INF("connected - GET_INFO >>> err:%d", err);
	// LOG_INF("connected - Connected as %s", info.role == BT_CONN_ROLE_CENTRAL ? "central" : "peripheral");
	// LOG_INF("connected - Conn. interval is %u units", info.le.interval);
	err = bt_conn_set_security(conn, BT_SECURITY_L2);
	LOG_INF("connected - Set_Security >>> err:%d", err);

	err = bt_conn_le_param_update(conn, conn_param2);
	LOG_INF("connected - bt_conn_le_param_update (err %d)", err);

	err = bt_conn_le_phy_update(conn, BT_CONN_LE_PHY_PARAM_2M);
	LOG_INF("connected - PHY >>> err:%d", err);

	err = bt_conn_le_data_len_update(conn, BT_LE_DATA_LEN_PARAM_MAX);
	LOG_INF("connected - data_length >>> err:%d", err); 

	err = bt_scan_stop(); // success: 0 or -120
	LOG_INF("connected - SCAN_STOP (err %d)", err);
	
	err = bt_conn_get_info(conn, &info);
	LOG_INF("connected - GET_INFO >>> err:%d", err);
	LOG_INF("connected - Conn. interval is %u units", info.le.interval);

}


static struct bt_conn_cb conn_callbacks = {
	.connected    = connected,
	.disconnected = disconnected,
	.security_changed = security_changed,
	.le_param_updated = le_param_updated,
	.le_data_len_updated = le_data_length_updated,
	.le_phy_updated =  le_phy_updated,
    .le_param_req = le_param_req,

};

[Hung Bui]

Hi Seongmin, 

So you are testing between 2 nRF52840 DK ? 

Please make sure you erase the chip completely before testing. If they have already bonded before you test you may get the error. 

Please try to capture a sniffer trace each time you test so we can find the difference. 
We have a course on how to use the sniffer: 
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-6-bluetooth-le-sniffer/

[seongmincho]

Hung Bui said:

So you are testing between 2 nRF52840 DK ? 

yes. i have three nRF52840 dk

Hung Bui said:

Please make sure you erase the chip completely before testing. If they have already bonded before you test you may get the error. 

My development environment is as follows: [Toolchain Manager: v1.3.0, IDE: Visual Studio Code (VSCode), SDK: ncs v2.6.0, Windows 11 Pro].

So, when I flash, doesn't it automatically get completely erased?

[Hung Bui]

Hi, 
To completely erase the chip you would need to click the double arrow:

[seongmincho]

Thanks for the great tip!

Is there a fundamental way to solve this issue? I think I might have read somewhere that paired devices are stored in non-volatile memory

[Hung Bui]

Have you solved the problem ? If you not  please don't click Verified Answer. 

Please clarify if you do a full erase you fix the issue. 

Yes bond/pair information is stored in non-volatile memory. This way when you restart the device it would be able to connect and reencrypt the link with paired device. 

[seongmincho]

Yes, it's been resolved. Thank you.

Could you tell me more specifically about 'bond/pair information is stored in non-volatile memory'?"

[Hung Bui]

Hi Seongmin, 
For example when your phone is paired with your Bluetooth headset. And when you turn off and on  your Bluetooth headset (or when it run out of battery) you don't have to re-bond/pair with the phone again, correct ?
To be able to do that the device has to store the bond information on non-volatile memory so that when it reset/power on-off it doesn't lose bond information. 

In your case, you get error -12 could be because on one side of the connection the bond information has for some reason been erased when the other device still keep the bond information and it won't allow a new bond until the current bond information has been erased.