ERROR:Connection Request Failed, reason 7

[Dev]

I am using a NRF52-based platform and have BLE code based on the ble_app_hrs_c Hear rate monitor system.

Having set up for scan, I see many device (we have a lot of beacons around).

I can also see the device I wish to connect to and even read values advertised, such as RSSI.

However, when I attempt connection, the call returns with the above error.

I looked a the SDK code (13.0.0) and that error seems to be invalid parameter.

I have checked through the parameters and they are as in the example. I did modify most of the parameters one by one to no avail.

I also checked the stack init, it is identical to the example.

I have no whitelisting.

Since the scan works, BLE is obviously operating.

Is there a noob issue I am missing, although I am not a noob to BLE or BT in general.

[Dev]

It would appear that, somewhere, someone missed something.

I decided to restart from the example and match up, line by line.

It seems that the previous engineer decided not to register service UUIDs, which seems reasonable since we are only interested in reading services, not advertising them.

However, after registering one, arbitrarily choosing the Heart Rate service, the discovery worked.

Now, all I have to do is proceed through the rest of the requirements to actually read a characteristic.

[Petter Myhre]

This doesn't really explain why sd_ble_gap_connect() returns 0x00000007 (NRF_ERROR_INVALID_PARAM), but it is working now?

[Dev]

The connection works and, since the BLE device I am connecting to has a battery service, I have configured that service only to be discovered at this time.

Unfortunately, the discovery fails at the point where the characteristics are going to be requested. The error (17) appears to be NRF_ERROR_BUSY.

Since the code for that service is the SDK battery service code, untouched, I am currently at a loss, perhaps the device is the issue.

If I can source an iPhone (or pay on this Android phone) I will create a device with the battery service and see if it is also giving busy.

[Dev]

I do get further packets changing the connection data length (to 27) and the MTU to 23 so perhaps it is busy because it wants to change these parameters?

In which case I would have to perform the discovery later somehow; there doesn't seem to be any code to try again for the characteristics at least.

I could just start the entire process over but it seems that the same issue would occur.

[Petter Myhre]

If it helped changing the MAX MTU you service discovery probably conflicts with the ATT MTU Exchange procedure (sd_ble_gattc_exchange_mtu_request() + BLE_GATTC_EVT_EXCHANGE_MTU_RSP), see this for more information. What if you initiate the service discovery when you get the NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event in gatt_evt_handler()?