Connection error in nrf52-ble-app-uart-c-multilink

[Avi]

I am using a code based on nrf52-ble-app-uart-c-multilink (https://github.com/NordicPlayground/nrf52-ble-app-uart-c-multilink)

If the central is working and the peripherals are incrementally connected, then it can connect to many devices (I have limited it to 16).

But if the peripherals stay connected (more than 4), and the central is powered on (or reset), then it will reset in every new attempt to connect with any peripheral.

i.e. endless resets.

The cause of the resey is in:

case NRF_BLE_SCAN_EVT_CONNECTING_ERROR:
{
err_code = p_scan_evt->params.connecting_err.err_code;
APP_ERROR_CHECK(err_code);
} break;

If I remove the APP_ERROR_CHECK, it doesn't reset, but it cannot connect to the reset of the peripherals. 

The only way to fix it, is to shut down all the peripherals and start connecting again incrementally. 

I recall that the advice was to increase the connection interval -

Can you explain how it affects? What should be the values if I want to connect up to 16 devices?

Thanks

Avi

[Einar Thorsrud]

Hi Avi,

Which error code do you get here (what is the value of err_code)?

Einar

[Avi]

Hi,

I get 

app_error_handler_bare(). err_code returns 0x11

and there is a reset right after

Avi

[Einar Thorsrud]

Hi Avi,

Hm, I see. The error code you get from p_scan_evt->params.connecting_err.err_code comes from a call to sd_ble_gap_connect() in nrf_ble_scan.c. 0x11 is NRF_ERROR_BUSY, but I do not immediately see how that can be returned by sd_ble_gap_connect(). Which SDK and SoftDevice version are you using?

Einar

[Avi]

I am using sdk 17.1, the latest

The code is multilink uart which was provided in the github.

According to the advice I got few months ago, I should increase the connection interval.

But I dont know why and to which value

[Avi]

I also tried to put the Eror_check of these lines into comments and the resets stopped

case BLE_GAP_EVT_CONNECTED:
err_code = ble_nus_c_handles_assign(&m_ble_nus_c[p_ble_evt->evt.gap_evt.conn_handle], p_ble_evt->evt.gap_evt.conn_handle, NULL);
//APP_ERROR_CHECK(err_code);

err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
//APP_ERROR_CHECK(err_code);

// start discovery of services. The NUS Client waits for a discovery result
err_code = ble_db_discovery_start(&m_db_disc, p_ble_evt->evt.gap_evt.conn_handle);
//APP_ERROR_CHECK(err_code);

[Einar Thorsrud]

Hi,

Avi said:

I also tried to put the Eror_check of these lines into comments and the resets stopped

Yes, that is expected. APP_ERROR_CHECK() triggers the error handler for any value other than 0 (NRF_SUCCESS), and the default error handler will reset in release mode. While I do not immediately see how you get this, you clearly get NRF_ERROR_BUSY from sd_ble_gap_connect() and in that case ignoring it and trying again later is safe and sensible.

I have not seen the discussion about connection interval, but in general the central with a lot of connections will be very busy. So if you do not have strict requirements for latency or throughput, using longer connection intervals make a lot of sense. That way there will be more slack, and so more time for other tasks (like scanning etc.). It also makes sense to use a long supervision timeout, for the same reason.