Disconnect during Connection Process after Successful Disconnect

[chalecampb]

8Q BTLE issue.pcapngBTLE connection failure.log

Hi guys,

We have an issue with some iOS devices that are disconnecting with reason 0x08, the connection timed out. The test procedure is,

1. We use various devices (5 iOS devices right now, also some Android) to connect to the peripheral

2. Wait some time (20s or so) and then disconnect (within our app).

3. Reconnect to the peripheral

4. After several tries, when we try to connect the peripheral immediately disconnects with 0x08

The problem is, we were looking into iOS disconnects on the forum and found several discussions on similar disconnects with iOS, and noted some differences and similarities to our situation.

1. The device is disconnecting when connected to only certain iOS devices, which would indicate the bluetooth spec violation. Unfortunately the disconnect reason we see is that it is just timing out.

2. It was recommended to increase the crystal PPM to allow a greater tolerance from the master. This didn't help anything.

3. We checked all disconnect points in our code and found that the disconnect is always initiated by the master (the iOS device, by the above testing) until the 0x08 disconnect occurs. After this, we can no longer connect to the softdevice. We thought it might be a connection parameters update failure or something, that does not seem to be the case.

4. We checked the iOS connection parameter spec, and it meets all requirements

5. We saw that, according to some reports, the iOS device was disconnecting after some inactivity. We see successful transmissions throughout the connection, until something happens to prevent further connection.

6. We've ruled out a noisy area because most devices work OK, except for the iOS devices listed in the environment section.

Our environment is

• GCC 4.9.2 and the Makefile solution
• nRF51 SDK v10.0.
• SD110 v8.0.0
• Raytac MDBT40 module (which we have not had problems with in thousands of units shipped, we have to think this is software).
• Working devices include the iPad Mini (9.3.5), iPhone6 (10.2.1), Google Pixel XL
• Failing device - iPad Pro (9.3.2) iPad4 (10.0.2) and iPhone SE

I am asking for more logs. Are there any further debug steps that I can perform in the meantime? The app code that we are using hasn't changed, the only thing we did was switch from Keil to GCC using stationary for other projects that we have deployed to production. As far as we can tell, the error is happening within the softdevice and we are only receiving the event about what happens. Is it possible we've caused some sort of race condition or bad state?

Thanks, -Alex

EDIT: Hi all, I am attaching the nRF sniffer logs that were provided to me. The three connection events are at packets 3673, 5481, and 6392. I don't see traffic above the link layer in the first two connection attempts. It looks like the third attempt negotiates successfully. On what I believe are the unsuccessful attempts, I see CONNECT_REQ, then LL_VERSION_IND, LL_FEATURE_REQ, LL_FEATURE_RSP, empty data frames, then LL_CHANNEL_MAP_REQ, a connection parameter update request, then nothing. Is it possible that the connection parameters update request is causing an issue? I would expect to see some kind of link termination after that, if that was the case, instead about 1s afterwards we start avertising (so, the link is dead).

[endnode]

Hi Alex,

Firstly if some device terminates the link it doesn't immediately means it violates BT SIG specification;) Get the RF logs from Nordic Sniffer (or from some more expensive device if available), I guess you will see what is really happening instead of assuming from incomplete iOS and RTT logs.