• State Verified Answer
  • Replies 5 replies
  • Subscribers 61 subscribers
  • Views 8227 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
  • 0

    Which connection parameters are used in this case? What is the connection interval and supervision timeout set by the central in the connection request? do the peripehral send an connection parameter update request?

    For clearification: you only have two active peripheral linkes when this is happening? Are you doing anything else? Advertising or scanning? If you are doing advertising and scanning what are the parameters?

  • 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.

  • 0

    Which softdevice version do you use? If using v4.0.2 (delivered with the SDK), can you try v4.0.3 that add some bugfixes?

  • 0

    Hi,

    The issue seems to be in the nrf_ble_gatt module. By default this module have set the peripheral and central link counts to 1, making the GATT link count 2:

    #define NRF_BLE_CENTRAL_LINK_COUNT 1
#define NRF_BLE_PERIPHERAL_LINK_COUNT 1

#define NRF_BLE_GATT_LINK_COUNT (NRF_BLE_PERIPHERAL_LINK_COUNT + NRF_BLE_CENTRAL_LINK_COUNT)

    When the gatt handler receives an event, it checks that the connection handle is less than NRF_BLE_GATT_LINK_COUNT. If the connection handle is above this value, the handler will return without handling the event.

    When you connect multiple times, the connection handle will continue increasing until it reaches PERIPHERAL_LINK_COUNT - 1, set in your main.c code.

    The solution is to redefine NRF_BLE_CENTRAL_LINK_COUNT and NRF_BLE_PERIPHERAL_LINK_COUNT to reflect the number of links supported by your application. This can either be done by changing the defines directly in *nrf_ble_gatt.h", or by setting it in the C/C++ preprocessor symbols:

    NRF_BLE_CENTRAL_LINK_COUNT=0 NRF_BLE_PERIPHERAL_LINK_COUNT=4

    This issue have been reported internally. Please also have a look at these threads: [1] [2].

    Best regards,

    Jørgen

Related