iPhone7 + nrf52 + SDK12/s132 doesn't connect

[Ray]

I have an odd situation. I've been using an iPhone 5 and 6 to connect to, and test against, both an nRF51 (redbear nano) and the same code built for nRF52. It works fine.

Today I provisioned an iPhone 7, with the latest version of ios of course.

And my app works perfectly fine with the nRF51, but it is completely unable to talk with the nRF52.

When I explore using nRF Connect on the iPhone 7, as you'd expect I can see everything perfectly when looking at the nRF51.

But when I explore the nRF52 using nRF Connect, and tap the advertised device, something different happens. On the Service screen, it says "Connected", however there are zero advertised services listed. It is truly bizarre.

Using wireshark I've done a capture - see response.

I am not an expert at on-wire analysis or even wireshark, so I'm hoping that you might be able to suggest what I do to take next steps to debug.

Your thoughts would be appreciated; thanks.

[Ray]

Actually, here are some better captures. This shows the protocol differences much more clearly.

This is a capture of the iPhone 7 using nRFConnect (not my app).

This capture is the IPhone7/nRFConnect connecting to an nRF51: dl.dropboxusercontent.com/.../nrfconnect-nrf51.pcapng

This is capture is connecting into the nRF52: dl.dropboxusercontent.com/.../nrfconnect-nrf52.pcapng

What you'll see is that all that happens on the nRF52 is:

1. SLAVE LL_VERSION_IND

2. SLAVE LL_VERSION_IND

3. MASTER LL_VERSION_IND

4. SLAVE 35 Control Opcode: Unknown

5. MASTER 35 Control Opcode: Unknown

6. SLAVE LL_FEATURE_REQ

7. SLAVE L2CAP Sent

8. MASTER LL_FEATURE_RSP

...and that's all. There's no further dialog, and no services listed in NRF Connect.

[Ray]

I know that this hasn't gotten attention yet, but I really hope someone from Nordic would please comment because it's really a blocker.

I have now reduced this to being an SDK V12 issue. Meaning, the following all work perfectly with my app and Nordic's own: iPhone 5s + nRF51822 + SDKV11/S130 iPhone 7 + nRF51822 + SDKV11/S130 iPhone 5s + nRF52822 + SDKV12/S132

It fails, with my app and Nordic's own, on: iPhone 7 + nRF52822 + SDKV12/S132

FYI, because I know that this is likely to be the very first thing that a Nordic employee would reasonably ask, I've now eliminated my app from the equation.

These two captures are from the SDKV12 ble_peripheral hrs app, using the up-to-date nRF Toolbox app on the iPhone.

I'm running the hrs app on my nRF52832.

This capture is done using the iPhone 5s running iOS 9.3.5, and it works perfectly:

dl.dropboxusercontent.com/.../hrs-nrf52-iphone5s-good.pcapng

This capture is done using the iPhone 7 running iOS 10.0.1, and it fails the same way as my app failed above:

dl.dropboxusercontent.com/.../hrs-nrf52-iphone7-bad.pcapng

[RK]

Doubt it's an SDKV12 SDK issue, more likely an S132 V3 issue. The captures don't show anything particularly interesting, it does show the exchange of max TX/RX length information (LL data length) in the bad capture because the softdevice identifies as BTLE 4.2.

It would be interesting to see a dump of iPhone7 -> S132V2 (SDK11 if you like) or to nrf51822 running S130, that should show a similar start. The dump you have the phone is BTLE 4.1

I don't understand the random L2CAP message from the master in the middle of the whole thing, in either dump, it's marked as a continuation but doesn't continue anything.

I'd be inclined to say iOS bug at this point. I don't know if any phone previous to iPhone 7 identifies as BTLE 4.2, and there can't be many products out there running S132V3. The nRF52 has replied to everything, the phone isn't asking more questions, which it should be.

[Ray]

Well indeed it works with the sdk11 soft device. And way above you will see a capture of the iPhone 7 talking to an nrf51.

Bottom line is that indeed it is likely softdevixe behavior that needs to be fixed to do whatever it was that it used to do in the sdkv11 softdevice.

[RK]

No I still think it's iOS BLE4.2 support which is most-likely at fault here. The nRF52 has replied to every message sent by the phone, properly, fully and completely and continues to respond to empty PDUs which the phone continues to send. The connection isn't timing out, so the phone isn't expecting a reply from the nRF52 which it's not getting. iOS hasn't sent an MTU request, not that it really needs to, but it's unusual, however the next request, either MTU or feature or discovery needs to come from iOS, there's nothing the softdevice has to send at this point.

And in the previous iPhone7/SD130 capture you can see that the softdevice responds to the data length request with unknown, that's the point of difference. In the S132V3 version, nRF responds with 0x1b as the tx and rx lengths, correctly. It's after that that iOS stops doing anything.