• State Verified Answer
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 8248 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 122352
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

LMP Response Timeout - experimental_ble_app_multiperipheral_pca10040_s132

Denna

experimental_ble_app_multiperipheral_pca10040_s132 connectivity issue.zip

I’m getting an LMP Response Timeout disconnect reason about 50% of the time when trying to get the nRFConnect App running on either an Android Pixel or iPhone 7 (running the latest OS versions) to connect to the pca10040 dev board. I’m running the experimental_ble_app_multiperipheral_pca10040_s132 example project on the PCA10040 dev board. This issue only occurs when the PERIPHERAL_LINK_COUNT is more than 2.

We are hoping to use this example application as a starting point for a project that we recently began and need to determine quickly whether this is an issue with the example application or the SoftDevice. If this is an issue with the SoftDevice, then we may need to change our architecture.

Here is the debug log when the iPhone connects successfully (similar to Pixel):

Rec:(2017/05/25, 03:02:01.255)APP:DEBUG:BLE stack event: 0x10
APP:INFO:Connected with link 0x0 established.
Rec:(2017/05/25, 03:02:01.441)APP:DEBUG:BLE stack event: 0x21
APP:DEBUG:Unhandled BLE stack event: 0x21
nrf_ble_gatt:DEBUG:Peer on connection 0x0 requested a data length of 251 bytes.
nrf_ble_gatt:DEBUG:Updating data length to 27 bytes on connection 0x0.
APP:DEBUG:BLE stack event: 0x22
APP:DEBUG:Unhandled BLE stack event: 0x22
nrf_ble_gatt:DEBUG:Data length updated to 27 on connection 0x0.
nrf_ble_gatt:DEBUG:max_rx_octets: 27
nrf_ble_gatt:DEBUG:max_tx_octets: 27
nrf_ble_gatt:DEBUG:max_rx_time: 328
nrf_ble_gatt:DEBUG:max_tx_time: 328
APP:DEBUG:BLE stack event: 0x55
APP:DEBUG:Unhandled BLE stack event: 0x55
nrf_ble_gatt:DEBUG:Peer on connection 0x0 requested an ATT MTU of 185 bytes.
nrf_ble_gatt:DEBUG:Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0.
Rec:(2017/05/25, 03:02:01.889)APP:DEBUG:BLE stack event: 0x50
APP:DEBUG:Unhandled BLE stack event: 0x50
Rec:(2017/05/25, 03:02:02.521)APP:DEBUG:BLE stack event: 0x52
Rec:(2017/05/25, 03:02:21.510)APP:DEBUG:BLE stack event: 0x12
APP:DEBUG:Unhandled BLE stack event: 0x12

Here is the debug log when the Pixel connects then disconnects with the LMP Response Timeout reason 0x22:

Rec:(2017/05/25, 03:19:24.866)APP:DEBUG:BLE stack event: 0x10
APP:INFO:Connected with link 0x2 established.
Rec:(2017/05/25, 03:19:25.018)APP:DEBUG:BLE stack event: 0x21
APP:DEBUG:Unhandled BLE stack event: 0x21
Rec:(2017/05/25, 03:19:47.068)APP:DEBUG:BLE stack event: 0x50
APP:DEBUG:Unhandled BLE stack event: 0x50
Rec:(2017/05/25, 03:20:04.933)APP:DEBUG:BLE stack event: 0x11
APP:INFO:Connection 0x2 has been disconnected. Reason: 0x22

BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST is the 0x21 event. BLE_GAP_EVT_DATA_LENGTH_UPDATE is the 0x22 event that is not sent when the issue occurs.

I’ve also seen this debug log when the iPhone connects then disconnects with the Connection Timeout reason 0x8:

Rec:(2017/05/25, 03:25:40.358)APP:DEBUG:BLE stack event: 0x10
APP:INFO:Connected with link 0x2 established.
Rec:(2017/05/25, 03:25:40.548)APP:DEBUG:BLE stack event: 0x21
APP:DEBUG:Unhandled BLE stack event: 0x21
Rec:(2017/05/25, 03:26:20.450)APP:DEBUG:BLE stack event: 0x11
APP:INFO:Connection 0x2 has been disconnected. Reason: 0x8

I have seen this issue with PERIPHERAL_LINK_COUNT set to 3, 4, 5, and 8. I cannot reproduce the issue when PERIPHERAL_LINK_COUNT is set to 1 or 2.

Here is my testing procedure. Perform the following steps using the nRF Connect App while monitoring the NRF_LOG output (with the NRF_LOG severity level set to “Debug”):

1. Connect from iPhone 7 to the Nordic_Blinky dev board
2.	Connect from Pixel to the Nordic_Blinky dev board
3.	Disconnect from iPhone 7 from the Nordic_Blinky dev board
4.	Disconnect from Pixel from the Nordic_Blinky dev board
5.	Connect from Pixel to the Nordic_Blinky dev board
6.	Connect from iPhone 7 to the Nordic_Blinky dev board
7.	Disconnect from Pixel from the Nordic_Blinky dev board
8.	Disconnect from iPhone 7 from the Nordic_Blinky dev board
9.	Connect from iPhone 7 to the Nordic_Blinky dev board
10.	Connect from Pixel to the Nordic_Blinky dev board
11.	Disconnect from Pixel from the Nordic_Blinky dev board
12.	Connect from Pixel to the Nordic_Blinky dev board
13.	Disconnect from iPhone 7 from the Nordic_Blinky dev board
14.	Connect from iPhone 7 to the Nordic_Blinky dev board
15.	Disconnect from iPhone 7 from the Nordic_Blinky dev board
16.	Disconnect from Pixel from the Nordic_Blinky dev board
17.	Repeat steps 1-16 until issue is observed
Parents
  • 0

    I'm using the experimental_ble_app_multiperipheral_pca10040_s132 example project as-delivered in the SDK. The only modifications that I made to the example app are:

    1. Set NRF_LOG severity level to "Debug" in the sdk_config.h Configuration Wizard
    2. Added some minor NRF_LOG_DEBUG prints to the on_ble_evt() function in main.c

    Looking at lines 82-85, it looks like the as-delivered connection parameters are as follows:

    #define MIN_CONN_INTERVAL               MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(200, UNIT_1_25_MS)
#define SLAVE_LATENCY                   0
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)

    I have a Sodera LE Capture file that shows this issue occurring after the third connection request (frame 21,238) ... I've attached it to the original post.

    During this Sodera LE Capture I performed the following test procedure:

    1. Connected to the dev board with the iPhone 7 (frame# 8,768)
    2. Connected to the dev board with the Pixel (frame# 16,150)
    3. Disconnected from the dev board using the Pixel (frame# 20,787)
    4. Disconnected from the dev board using the iPhone 7 (frame# 21,069)
    5. Connected to the dev board with the iPhone 7 (frame# 21,238)

    Note that the dev board does NOT respond to the LL_LENGTH_REQ on frame# 21,263.

    The dev board does send the L2CAP Connection Parameter Update Request on frame# 23,806. And the iPhone 7 does accept on frame# 23,810, but the iPhone does NOT send a LL_CONNECTION_UPDATE_IND thereafter with the accepted connection parameters.

    To answer your clarification questions:
    This example is a peripheral/advertiser example that allows multi-connections as a peripheral. It advertises at an interval of 40 ms while maintaining up to PERIPHERAL_LINK_COUNT connections. PERIPHERAL_LINK_COUNT is set to 4 in the example as-delivered in the SDK.

Reply
  • 0

    I'm using the experimental_ble_app_multiperipheral_pca10040_s132 example project as-delivered in the SDK. The only modifications that I made to the example app are:

    1. Set NRF_LOG severity level to "Debug" in the sdk_config.h Configuration Wizard
    2. Added some minor NRF_LOG_DEBUG prints to the on_ble_evt() function in main.c

    Looking at lines 82-85, it looks like the as-delivered connection parameters are as follows:

    #define MIN_CONN_INTERVAL               MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(200, UNIT_1_25_MS)
#define SLAVE_LATENCY                   0
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)

    I have a Sodera LE Capture file that shows this issue occurring after the third connection request (frame 21,238) ... I've attached it to the original post.

    During this Sodera LE Capture I performed the following test procedure:

    1. Connected to the dev board with the iPhone 7 (frame# 8,768)
    2. Connected to the dev board with the Pixel (frame# 16,150)
    3. Disconnected from the dev board using the Pixel (frame# 20,787)
    4. Disconnected from the dev board using the iPhone 7 (frame# 21,069)
    5. Connected to the dev board with the iPhone 7 (frame# 21,238)

    Note that the dev board does NOT respond to the LL_LENGTH_REQ on frame# 21,263.

    The dev board does send the L2CAP Connection Parameter Update Request on frame# 23,806. And the iPhone 7 does accept on frame# 23,810, but the iPhone does NOT send a LL_CONNECTION_UPDATE_IND thereafter with the accepted connection parameters.

    To answer your clarification questions:
    This example is a peripheral/advertiser example that allows multi-connections as a peripheral. It advertises at an interval of 40 ms while maintaining up to PERIPHERAL_LINK_COUNT connections. PERIPHERAL_LINK_COUNT is set to 4 in the example as-delivered in the SDK.

Children
No Data
Related