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.

[run_ar]

As endnode says, it would be interesting to see sniffer traces that shows this problem. Thanks.

[chalecampb]

@endnode I am not referring to the fact that the device terminates the link as a BT SIG violation. I am referring to a specific set of posts on the forum that details a problem in which the iOS device, after 8.3.2, can potentially send multiple packets which raises a link layer error.

[run_ar]

In the question, are you saying that you switched copmiler from Keil to GCC, and this started after the switch? No changes to the codebase? Are you sure you are not missing any preprocessor symbols?

Have you been able to recreate this behavior using an SDK example so I can try to recreate it here (Unfortunately I don't have a matching idevice/iOS version combination so it might not be possible for me to recreate it...)?

Do you see the same disconnect issue if you use nRF connect for iOS instead of your own app?

[chalecampb]

Hi run_ar,

1. Yes, I asked to check if the problem still occurs with LightBlue and it still disconnected
2. We did switch from Keil to GCC. This project was the first project we did with the nRF51822. The codebase used Keil because the GCC stationary was not complete at that time. Since then we did 2 other projects, a central and a peripheral. In switching from Keil to GCC, we started from the peripheral makefile that we already had (and shipped). All of the preprocessor directives are the same, the only thing that changed was the include and c file list. And the name.

The issue doesn't occur with the other peripheral project that we use.