This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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

Parents
  • 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.

Reply
  • 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.

Children
  • 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?

Related