• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 67 subscribers
  • Views 7147 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104882
Options
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

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

  • 0 in reply to Audun

    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.

Related