Disconnect very quickly after connected,reason:0x3E

[jay wang]

Hi Supporter:

Hardware:nRF52840 dongle

Software: basic example "ble_app_interactive", s140_nrf52_6.1.1_softdevice

There is a strange problem,I connect my machine with iphone nrf connect, connect is ok, discovery all normal, But when i use Dongle with the software "ble_app_interactive", It's quickly disconnect.Log:

<info> app: CENTRAL: Connecting...
<debug> app: Connection Request Failed, reason 8
Connected to address: 00 1D 48 2F 18 29
<info> app: CENTRAL: Connected, handle: 0.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connecting to target 29182F481D00
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E

I test my central dongle with other dongle which use example "usbd_ble_uart",It's connect ok;Log

<info> app: CENTRAL: Connecting...
<debug> app: Connection Request Failed, reason 8
Connected to address: F6 17 FA C0 12 F1
<info> app: CENTRAL: Connected, handle: 0.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connecting to target F112C0FA17F6
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 64 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 64 bytes (desired: 247) on connection 0x0.
Current MTU: 64
<debug> nrf_ble_gatt: ATT MTU updated to 64 bytes on connection 0x0 (response).
MTU changed successfully
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<info> app: Data length updated to 251 bytes.

But when i connect peripheral  dongle with this central dongle first, and then i connect my machin, It's connect ok. 

It's very strange.00-connect_fail.pcapng00-connect_success.pcapng

I use sniffer crab some bags. 

Attachment is my sniffer bags. 

Hope my description is clearly .

Thanks any help.

[jay wang]

Hi Hung Bui,

Good weekend, Thanks for your reply.

For you question:

1.How often do you see the issue-  every time.when i connect it first.

2.Have you even managed to connect the central to the peripheral - My "nRF52840 dongle" connect to iphone is ok.But it's cannot connect to my MACHINE(It's linux host and maybe TI chip,not very sure).

3.Have you tried to connect using a phone to your peripheral- Yes ,My iphone connect to my MACHINE is ok, Not any problem.I use the app NRF CONNECT.

4.Please try to test with a normal BLE application in the SDK-- My application is used the example "ble_app_interactive" which is in the SDK.

5.Could you check the log on the peripheral-- I can see the log in my MACHINE (Use the HCIDUMP tool in linux host).It's can dicovery my central device, and putout the correct mac address, But it's display disconnect very soon .I can send the log to you in monday.

And i want to expain the attachment 

00-connect_fail.pcapng : This packet is the process which connected fail. 

00-connect_success.pcapng : When my nRF52840 Dongle have connected  a peripheral before, I can connect my MACHINE as second link success, This packet is the proccess which connect success as second link. 

It's can connect success when it's as second link, This is why i feel so strange.  

If the slave cannot catch the connect request, why is connect success as sencond link? I compare the "fail "and "success" packet, The connect request content different is "window offset", I  suspect this filed cause this problem,But the window offset and window size cannot set through soft device.

[Hung Bui]

Hi Jay, 
Thanks for the info. There are some devices that don't support window offset = 0 . We have created a compatibility mode to avoid using window offset = 0. 
Please have a look at the ble_gap_opt_compat_mode_1_t struct quoted here:

/**@brief Compatibility mode 1 option.
 *
 * @details This can be used with @ref sd_ble_opt_set to enable and disable
 *          compatibility mode 1. Compatibility mode 1 is disabled by default.
 *
 * @note Compatibility mode 1 enables interoperability with devices that do not support a value of
 *       0 for the WinOffset parameter in the Link Layer CONNECT_IND packet. This applies to a
 *       limited set of legacy peripheral devices from another vendor. Enabling this compatibility
 *       mode will only have an effect if the local device will act as a central device and
 *       initiate a connection to a peripheral device. In that case it may lead to the connection
 *       creation taking up to one connection interval longer to complete for all connections.
 *
 *  @retval ::NRF_SUCCESS Set successfully.
 *  @retval ::NRF_ERROR_INVALID_STATE When connection creation is ongoing while mode 1 is set.
 */
typedef struct
{
   uint8_t enable : 1;                           /**< Enable compatibility mode 1.*/
} ble_gap_opt_compat_mode_1_t;

This mode can be enabled by calling sd_ble_opt_set().

I don't think there is an option to do this in the CLI interface, but you can add the call directly in the code of ble_app_interactive. 

[jay wang]

Thanks for reply.

I have found the compatibility mode today,But unfortunatly, This phenomenon is still hanppening.I catch the packet with sniffer,The window offset is not 0 when enabled the compat_mode_1.I'm sure that my setting is taken effort. 

 I've run out of my ideas.

[Hung Bui]

Hi Jay, 

 

jay wang said:

The window offset is not 0 when enabled the compat_mode_1.

 Could you clarify what's the window offset was ? was it 0 or something else ? Could you provide a sniffer trace ? 

[jay wang]

The window offset always equal the connect interval when i enabled compat_1_mode.I add the sniffer trace in attachment:00-enabled-compat.pcapng.Please check it.

00-enabled-compat.pcapng

[Hung Bui]

Hi Jay, 
 It could be an incompatibility issue with the Linux device you have. 

I'm not 100% sure why it doesn't work with our device, but you may want to check the clock source of the Linux device. It seems to me that it has wrong clock configuration (specifically crystal/RC tolerance) that make it missed the window size. 

I'm not sure if it helps but you can try to reduce the LFCLK tolerance on the nRF52 , it might help in this case. Other than that I ran out of idea on how to fix this. 

[jay wang]

OK, Thanks.

I am agree with you, It's an incompatibility issue.

I'll try your ideas. I will tell you if any update.