BLE Connection Issues with nRF52832 Multi-Device Setup

[siltvm]

We are currently developing a project using the nRF52832 as the microcontroller, Segger Embedded Studio version 5.42a as the IDE, and the nRF5 SDK 17.0.2. We began by creating a concurrent central and peripheral switching example project. Subsequently, we integrated the NUS (Nordic UART Service) client and peripheral functionalities into the nRF Relay example project.

Our setup involves three device types:

1. Response Device: This device operates as both a central and a peripheral. In its central role, it scans for advertising packets from BLE beacon sensors. In its peripheral role, it awaits BLE connections from a central device. We have four response devices.
2. Submaster Gateway Device: This device facilitates data transfer between the connected response devices and the supermaster device. It acts as both a central and a peripheral. In its central role, it establishes connections with the peripheral role of the response devices. In its peripheral role, it waits for connections from the supermaster gateway.
3. Supermaster Gateway Device: This device is the final destination for data relayed through the submaster gateway. We have one supermaster device.

The code for these three devices is based on the nus_c and nus integrated nrf_relay example project

Initially, when we power on the four response devices, followed by the submaster device, all four response devices successfully connect to the submaster device. Then, when we power on the three additional response devices and the supermaster device, these three response devices and the submaster device successfully connect to the supermaster device. Data transmission and reception between any of the response devices and the supermaster device function correctly in this scenario.

However, if we power on the devices in a random order, connection issues arise. Devices frequently connect and then disconnect, exhibiting unstable behavior. This leads us to suspect potential timeout issues.

The following BLE macro definitions are used across all devices (response, submaster, and supermaster):

#define PERIPHERAL_ADVERTISING_LED BSP_BOARD_LED_2
#define PERIPHERAL_CONNECTED_LED BSP_BOARD_LED_3
#define CENTRAL_SCANNING_LED BSP_BOARD_LED_0
#define CENTRAL_CONNECTED_LED BSP_BOARD_LED_1
#define DEVICE_NAME "nRF Relay" /**< Name of device used for advertising. */
#define MANUFACTURER_NAME "NordicSemiconductor" /**< Manufacturer. Passed to Device Information Service. */
#define APP_ADV_INTERVAL 300 /**< The advertising interval (in units of 0.625 ms). This value corresponds to 187.5 ms. */
#define APP_ADV_DURATION 18000 /**< The advertising duration (180 seconds) in units of 10 milliseconds. */
#define APP_BLE_CONN_CFG_TAG 1 /**< Tag that identifies the SoftDevice BLE configuration. */
#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000) /**< Time from initiating event (connect or start of notification) to the first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000) /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT 3 /**< Number of attempts before giving up the connection parameter negotiation. */
#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 0 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 0 /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_NONE /**< No I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size in octets. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size in octets. */
#define HART_RATE_SERVICE_UUID_IDX 0 /**< Hart Rate service UUID index in array. */
#define RSCS_SERVICE_UUID_IDX 1 /**< RSCS service UUID index in array. */
#define NUS_SERVICE_UUID_TYPE BLE_UUID_TYPE_VENDOR_BEGIN /**< UUID type for the Nordic UART Service (vendor specific). */
#define APP_BLE_OBSERVER_PRIO 3
#define DB_DISCOVERY_INSTANCE_CNT 2 /**< Number of DB Discovery instances. */
#define BUZZ_PIN 20
#define POWER_STS 19
#define BATTERY_ON 22
#define POWER_ON 0
#define POWER_OFF 1
#define CLEAR 0
#define SET 1

static ble_hrs_t m_hrs; /**< Heart Rate Service instance. */
static ble_rscs_t m_rscs; /**< Running Speed and Cadence Service instance. */
static ble_hrs_c_t m_hrs_c; /**< Heart Rate Service client instance. */
static ble_rscs_c_t m_rscs_c;
BLE_NUS_C_ARRAY_DEF(m_ble_nus_c_arr, NRF_SDH_BLE_CENTRAL_LINK_COUNT);
BLE_NUS_DEF(m_nus, NRF_SDH_BLE_TOTAL_LINK_COUNT);
NRF_BLE_GQ_DEF(m_ble_gatt_queue, NRF_SDH_BLE_CENTRAL_LINK_COUNT, NRF_BLE_GQ_QUEUE_SIZE);
NRF_BLE_GATT_DEF(m_gatt);
NRF_BLE_QWRS_DEF(m_qwr, NRF_SDH_BLE_TOTAL_LINK_COUNT);
BLE_ADVERTISING_DEF(m_advertising);
BLE_DB_DISCOVERY_ARRAY_DEF(m_db_discovery, 6);
NRF_BLE_SCAN_DEF(m_scan);
static uint16_t m_conn_handle = BLE_CONN_HANDLE_INVALID;
static uint16_t m_conn_handle_hrs_c = BLE_CONN_HANDLE_INVALID;
static uint16_t m_conn_handle_rscs_c = BLE_CONN_HANDLE_INVALID;
static uint16_t m_conn_handle_nus_c_arr[NRF_SDH_BLE_CENTRAL_LINK_COUNT];

Does having the same advertising and connection parameter delays on all three devices affect the issue? Or, is it possible that a connection problem occurs when one device tries to connect via BLE but another device is not ready?

[Hung Bui]

Hi, 
I would suggest to use a sniffer to try debugging. You can find why the connection is terminated. 

You can also find the termination reason on the device when it's disconnected. 

Please focus on this: 
<error> nrf_ble_gatt: sd_ble_gatts_exchange_mtu_reply() returned NRF_ERROR_INVALID_STATE.

Where do you call sd_ble_gatts_exchange_mtu_reply() ? 

Was the log from the Super master or the Sub master ?

[siltvm]

The given log is from the super master, and I could not find sd_ble_gatts_exchange_mtu_reply() within my super master code.

[Hung Bui]

Hi, 
If you want such feature, you would need to implement that. The submaster gateway shouldn't connect to the supermaster gateway as the central. This mean when the submaster scan for advertising packet, it would need a way to detect that it only connect to response node, not the supermaster. I think it's quite straight forward to do so. Just need to scan for either address, or the advertising name/data. 

[siltvm]

Hung Bui Okay, I will proceed as you suggested. I also have a question: are there any issues with scanning for or connecting to a central device while maintaining a peripheral connection? Additionally, what are the standard minimum delays required for a response device, sub-gateway, or super-master gateway to perform scanning and connection?

[Hung Bui]

Hi, 
I don't see a problem having a connection and then scan and establish another connection. It's our fundamental operation for multilink application. So, shouldn't be a problem. 
There is no requirement on the timing. Of course two connection can't be established at the same time (like exactly the same time) they should be established based on when the scanner catch the advertising packet and send the connect request. 

[siltvm]

When the submaster gateway initially starts advertising, and when Iam initiates a connection from the APK, it sometimes disconnects and shows:

Peripheral disconnected. conn_handle: 0x5, reason: 0x28

The APK then shows: Connection failed: write descriptor failed.

One more thing: I am not using any kind of bonding here. So, what are the possible causes of this issue?

This issue happens only sometimes  .

[Hung Bui]

Hi Siltvm, 

Error 0x28 is a bit strange because it's indicate an issue in the BLE stack timing ( BT_HCI_ERR_INSTANT_PASSED) either on the nRF52 or on the phone. Which phone did you use ? 

I would need to see your sniffer trace to be to check what happens there. 
You can find the guide on how to use the sniffer here: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-6-bluetooth-le-sniffer/