BLE remote connect to HID central NCS sample always disconnect.

[v630140]

Hi:

I have a BLE HID remote control that needs to be connected to the HID central(nRF52832).My SDK is NCS v1.8.0.

When I try to connect with the HID remote I get the log.

*** Booting Zephyr OS build v2.7.0-ncs1  ***
Starting Bluetooth Central HIDS example
I: 6 Sectors of 4096 bytes
I: alloc wra: 0, fb8
I: data wra: 0, 88
I: SoftDevice Controller build revision:
I: df c0 4e d6 1f 7c 66 09 |..N..|f.
I: 0a f5 2b a0 98 f2 43 64 |..+...Cd
I: 62 c5 a6 2a             |b..*
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 223.20160 Build 1719410646
I: No ID address. App must call settings_load()
Bluetooth initialized
I: Identity: F2:47:CD:22:65:3D (random)
I: HCI: version 5.2 (0x0b) revision 0x12b0, manufacturer 0x0059
I: LMP: version 5.2 (0x0b) subver 0x12b0
Scanning successfully started
Filters matched on UUID 0x1812.
Address: 8C:85:80:AA:16:56 (public) connectable: yes
Connected: 8C:85:80:AA:16:56 (public)
Failed to set security: -12
The discovery procedure succeeded
HIDS is ready to work
Subscribe to report id: 1
Subscribe to report id: 2
Disconnected: 8C:85:80:AA:16:56 (public) (reason 19)
HIDS client active - releasingFilters matched on UUID 0x1812.
Address: 8C:85:80:AA:16:56 (public) connectable: yes
Connected: 8C:85:80:AA:16:56 (public)
Failed to set security: -12
The discovery procedure succeeded
HIDS is ready to work
Subscribe to report id: 1
Subscribe to report id: 2

Connected: 8C:85:80:AA:16:56 (public)
Failed to set security: -12
The discovery procedure succeeded
HIDS is ready to work
Subscribe to report id: 1
Subscribe to report id: 2
Disconnected: 8C:85:80:AA:16:56 (public) (reason 19)

I try to change BT_SECURITY_L2 to BT_SECURITY_L1 but it still disconnected.

reason 19: BT_HCI_ERR_REMOTE_USER_TERM_CONN

Any idea what is wrong or how to solve it?

Thanks!

[Hung Bui]

Hi, 

Error -12 means BT_HCI_ERR_CMD_DISALLOWED. 
Could you provide the code so that we can test here ? 
Could test your HID remote with nRF Connect for Desktop BLE, and allow the keyboard and display when testing ? 

I suspect that there could be a chance that the configuration require the peer device to have keyboard and display. 

You may want to capture a sniffer trace so we can get to know what happened over the air. 

[v630140]

Hi:

sorry, I cannot provide the source code because the BLE remote(HID keyboard) control is provided by a third party.

And the HID central in NCS example I used hasn’t been modified in any way.

I tried to connect to the BLE remote control with nRF Connect for Desktop BLE but I don’t know how to allow the keyboard and display when testing.

Can you provide me with the operation steps? Thanks.

The picture below is the screen of my connection with the BLE remote control

Log from nRF Connect for Desktop BLE.

2022-01-03T09_45_43.902Z-log.txt

Thank you for your help.

 

[Hung Bui]

Hi,

You can configure the nRF Connect for BLE security setting (before you connect to the device) as follows: 

Then in the next window you select "Keyboard and display": 

[v630140]

Hi:

I already allow the keyboard and display when testing, but the connection will be disconnected after a few seconds. 

Thanks.

Log:

10:30:35.256 Connecting to device

10:30:35.297 Connected to device 8C:85:80:AA:16:56: interval: 7.5ms, timeout: 4000ms, latency: 0

10:30:35.322 ATT MTU updated for device 8C:85:80:AA:16:56, new value is 247

10:30:35.647 Attribute value read, handle: 0x07, value (0x): 41-6E-6B-65-72-2D-41-52-00

10:30:47.318 Disconnected from device 8C:85:80:AA:16:56, reason: BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION

[Hung Bui]

I'm not sure what could be wrong here. We would need to have sniffer trace to get to know what failed. 
I found this case has similar error as yours: 

https://devzone.nordicsemi.com/f/nordic-q-a/79636/failed-to-set-security--12-whn-the-connection-is-happening-on-uart-example

Could you try the suggestion there to increase CONFIG_BT_SCAN_NAME_CNT ? 
Also please make sure you erased the chip before testing, so that we can be sure it was not be cause the maximum number of paired device was reached so it couldn't make new bonding (as suggested in the case)