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).

[run_ar]

How many peripheral device have you tested that behaves like this (That is how many different chips have you run this particular project on and seen this behavior)? What is your 32KHz clock source?

Could be interesting to see the logs from the apple device as well if you have access to them? They can be retrieved using xcode.

[chalecampb]

Hi run_ar,

1. I have requested XCode logs to see, I asked the app developer and he says there is no disconnect call unless the user manually presses disconnect

2. The clock source is an external xtal and capacitor pair, we use the same external clock circuit on all of our products in the same layout. The components are 1x FC-135 32.7680KA-AC and 2x GRM1555C1H120GA01D

support.epson.biz/.../doc_check.php

search.murata.co.jp/.../GRM1555C1H120GA01-01.pdf

3. The capacitor values are 12pF to account for around 2pF in trace capacitance. I just double checked and we are reading mean 32.768kHz, but the minimum and maximum measured frequency are 32720 and 32800. I'll check into why it measures that, since the crystal is rated at 20ppm.

In any case this is the only product and firmware we are seeing the issue on, so I would be surprised to see a hardware issue unless it is exacerbated by something we changed in the software.

Thanks, -Alex

[run_ar]

Since you say this only fail with certain centrals. And it looks like there is always a timeout. I would guess the central either stops sending packets or is sending them outside of the listening window. I see from the log the central ppm value is set to 31 to 50. If I remember correctly this has been changed to 250 on newer devices (or is it iOS version, not sure). But you say that you have already tried to increase the ppm value on the peripheral so I'm inclined to think the central stopped transmitting for some reason. Did you test the peripheral even with the 500ppm value? You wouldn't happen to have access to an ellisys sniffer so we can get a better trace? maybe see if the master actually stops sending packets (the nRF sniffer is great, but has some limitations...)?