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

[Tim Clark]

I'm wondering (hoping) if there is something that I'm not doing correctly ...

We have a BLE application on the nRF51822 which has been working nicely. It is a custom BLE Service/Characteristic which supports a command/response protocol that we've developed for reading the captured information on our device.

We also support DFU mode -- using the DFU bootloader example -- pretty much AS-IS, except for checking the (gpregret == 1) condition on reset (which we set in the main application via a BLE command).

What 'appears' to be happening is this :

1 -- BLE application is running, connected to the iOS App -- able to view data, etc.

2 -- DFU 'key' is hit in the App which does the following on the device : sd_power_gpregret_set(0x01); sd_nvic_SystemReset();

3 -- The device resets, detects the gpreget bit set -- and (successfully) enters DFU mode.

4 -- We use nRF Toolbox to update the F/W. All works well -- find DfuTarg, select file, file type, etc. Upload is successful. Device resets and is now running with new F/W.

5 -- Here is where it gets 'weird' ? In order to get the device to show-up again (even if I remove power from the device and then bring it back up) -- I must cycle BT Off/On on my iOS device! Our App is looking for it's desired Service UUID (0x1723) and Characteristic (0x1724) -- and doesn't find them.

6 -- Prior to cycling BT Off/On in the Settings Menu -- if I run an App that I downloaded on iTunes : itunes.apple.com/.../id525235616 -- then what I see are the Service/Characteristics (0x1530, 1531, 1523) which are the ones in the DFU Bootloader?!?!

SO -- it seems like somehow/someway? iOS is 'latching' those DFU characteristics -- even though the device is correctly advertising with it's non-DFU (1723/1724) Service/Characteristic.

As soon as I cycle BT Off/On on the iOS device -- even the BLE Tool shows the proper results (0x1723/1724) -- with the device being on throughout all this -- no change to/from DFU mode.

I'm wondering if it there is any chance that iOS is getting irk'd with the fact that the default DFU bootloader calls the device DfuTarg -- and our application code calls it something different?

Appreciate any input/guidance that you might have -- as it just can't be that we have to tell user's to cycle BT after a F/W update!

Cheers, -Tim

[Nathan]

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