DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Tim Clark — Wed, 31 Dec 2014 06:49:57 GMT

Still struggling with this one. I did find that the Nordic DFU Bootloader example doesn't have the Service Changed Characteristic enabled. So I enabled that. (It was always enabled in my Application F/W). But it still behaves (more or less) the same -- as if there is still some form of Caching happening on the iOS side? I even changed the DFU bootloader and my Application F/W to have the advertise with the identical device name -- just in case. No change.

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Marc Nicholas — Sat, 20 Dec 2014 01:19:59 GMT

The OP should really read Apple's own guidelines, per my previous suggestion. :)

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Audun — Sat, 20 Dec 2014 01:08:05 GMT

Ah, yes, I agree. I missed your point about choosing one or the other.

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Marc Nicholas — Sat, 20 Dec 2014 01:05:38 GMT

Altering the GATT table without Service Changed Characteristic is a violation of the Spec. If you read Audun's post carefully, he's suggesting either the Service Changed characteristic (the right way to do this) or "fooling" the device by using the same Services in both application and DFU "mode".

If you use the former, you don't need the latter.

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Audun — Sat, 20 Dec 2014 00:53:25 GMT

Altering the GATT database isn't in violation of the Bluetooth spec. The Service Changed characteristic exists explicitly to handle this situation: "If the list of GATT based services and the service definitions cannot change for the lifetime of the device then this characteristic shall not exist, otherwise this characteristic shall exist."

However, if this doesn't work with iOS, I suggest keeping the same GATT database both for normal operation and when the bootloader is active. That is, adding a dummy DFU Service in normal mode, and dummy other-Services in the bootloader.

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Marc Nicholas — Sat, 20 Dec 2014 00:37:52 GMT

By design, you cannot 'flush' the CoreBluetooth GATT cache. Even setting the CBCentral object to nil, or instantiating another CBCentral won't help in these circumstances.

I wouldn't recommend the second part of your suggestion as technically you're violating both Spec (removing Services is just as much a no-no as adding them without Service Discovery enabled) and Apple's guidelines for dealing with this situation.

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Audun — Sat, 20 Dec 2014 00:21:06 GMT

Hi Tim,

I agree with Nate and jt, this does indeed look like a caching issue.

One problem with the bootloader as it is now is that the bootloader has a completely different GATT database than your normal application. When a Central device re-connects to your nRF51, it expects that the GATT database is the same, so it can avoid doing a Service Discovery procedure (which takes time). Bluetooth does have functionality for dealing with this situation: one of the native characteristics on a BLE device is the "Service Changed Characteristic". The idea is that the GATT Server can use this to indicate to the GATT Client that the GATT database has changed (see developer.nordicsemi.com/.../a01060.html. There's not guarantee that the peer device will take action when this happens, but it's worth a try looking into. Note that with S110 v7.0.0 and later, you must specifically tell the stack to include this characteristic when enabling the stack (see developer.nordicsemi.com/.../a01045.html

You can also add the DFU Service to your normal GATT database before your other services. I mean, just add the Service to your database, but not include any of the actual bootloader functionality in there. This way the peer device will the the following services during normal operation:

DFU Service
Battery Service (for example)
Device Information Service (for example)
Your other Services

When the bootloader is active, the peer device will see the following services:

DFU Service

Thus you won't have to force flushing the cache in order to find the DFU Service in bootloader mode (as the DFU Service will now be at the exact same place in the GATT database), and hopefully you will see the full set of Services again when you resume normal operation.

It might be easier to "just" flush the cache when triggering the bootloader, but I'm not exactly sure how/if that can be done without disabling and re-enabling Bluetooth (I'm not an iOS developer).

Hope this helps!

Audun

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Marc Nicholas — Sat, 20 Dec 2014 00:14:53 GMT

Yes, there is something you're not doing correctly. You need to:

(1) Read the Bluetooth Spec. (2) Read Apple's Bluetooth Accessory Design Guidelines (maybe start here as it's only a few pages long and has the answer plainly written in it).

Both the reason why you are seeing this behaviour and the way to 'fix it' is included within these documents.

Contrary to the [incorrect] comments above, Apple's iOS behaviour is not erroneous and is 100% per the Bluetooth Spec. Nor was this suddenly introduced in iOS8. Apple are pretty serious about BLE and don't tend to cut corners, despite CoreBluetooth not being the most friendly API around ;)

-m

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Nathan — Fri, 19 Dec 2014 22:33:52 GMT

Tim,

This is probably the same bug I encountered awhile back while trying to get a DFU bootloader to work with iOS apps. My firmware used to work back on iOS 7, but broke when the phone was upgraded to iOS 8. What I eventually discovered is that in iOS 8, for some reason the Bluetooth stack will now save the advertising data of any Bluetooth smart device it connects to somewhere in memory at the moment of connection. The old advertising data will then be recalled and used the next time the peripheral advertises to the phone instead of the current advertising data. Therefore, except for first time connection the phone app will always be "one connection behind" in terms of what it reports is contained in the advertising data. Because I used the advertising data to tell the app when to use the bootloader as well, it got confused and couldn't connect up properly.

For now I'd avoid using the advertising data as a means to determine if your device wants to run normally or enter bootloader mode. If it's possible to do and your phone app is flexible enough, I'd recommend altering your bootloader advertising data to exactly match the firmware main data, and have your phone app always search for the common data. On connection, perform a service discovery and use the services the peripheral reports are available to determine what mode the device is in, and handle it appropriately from there. Alternatively, create a custom common service between the bootloader and main firmware app whose sole purpose in life is to send a one byte value to the phone to tell it whether the device is in bootloader or main code.

Nate

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

Tim Clark — Fri, 19 Dec 2014 01:57:06 GMT

Thanks for the suggestions!

I haven't checked the source code for nRF Toolbox (just downloaded from the App store) -- but it seems like our App must? be closing-out OK if nRF Toolbox is successfully discovering the DFU Service/Characteristic -- but then after nRF Toolbox is done -- I'm not able to see my device post-DFU.

Guess would be great to hear is if anybody has had issues using the nRF Toolbox DFU -- then their device not showing up afterwards?

RE: DFU on nRF51822 + iOS -- Have to toggle Bluetooth ON/OFF

jt — Fri, 19 Dec 2014 01:20:56 GMT

I had a similar issue where my iOS app wasn't properly handling a reconnect from the peripheral, so I had to also either toggle bluetooth on/off or reset the app. Did you confirm that your CBPeripheral object is set to nil upon a disconnect, if your CBPeripheral has a singleton/shared instance delegate, it's being managed properly, and that you re-enable scanning? Those 3 things contributed to me seeing that behavior, but all the root cause was on the iOS side.