• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 6770 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

Parents
  • 0

    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

Reply
  • 0

    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

Children
No Data
Related