• State Verified Answer
  • Replies 2 replies
  • Subscribers 62 subscribers
  • Views 1959 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 121829
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

iOS OTA Update on a secured link

ThierryC

Hi,

this question is more about iOS than nRF, but there's probably here some experience around this subject.

First the context : We have a product based on nRF51, S110 v7.3 and I recently implemented ANCS service requiring secured link (bonding) with iOS devices.

Everything works fine, until we tried to use our OTA firmware Upgrade.

We use our own custom bootloader to do that which doesn't use the Nordic device manager and so doesn't restore the secured link with iOS.

And the problem we have is the following : after we restart our FW in BSL mode, waiting for DFU, the iOS is connecting to the device (we can see this on the device log), but on the iOS "list of BLE device" it says "not connected". And at this point, our iOS application which is trying to make the DFU is NOT ABLE to CONNECT to the device (using iOS API : CBCentralManager.connectPeripheral) and so not able to make the Firmware Upgrade !

As a WORKAROUND, we found that if we tell iOS to "forget this device" before OTA Firmware Upgrade, the Application can reconnect and update the Firrmware.

So my questions are :

  1. Is it expected that iOS API have no way to connect to this device if the secure link is not restored ? Or is there a way to get this connection from iOS application ?
  2. What is the best practice for OTA FW upgrade on device connected via secured link ? Is the Bootloader supposed to restore this secure link ?

Any hint, link or input is welcome...

  • 0

    Hi,

    1. Correct. The phone expect that the device has the stored bond information (LTK) and expect the link to be encrypted. If the device doesn't have that, it will disconnect.

    2. Yes, you can follow what we do in our bootloader (in SDK v11 and earlier) and the buttonless dfu example that we we forward bond information from the application to the bootloader (via RAM).

    An easier option, if you don't need the link to be encrypted when doing DFU, is to change the BLE address when you are in DFU mode, so the phone will think that the device is a new device and won't enforce the encryption.

    You need to retain the bond information when doing DFU so that when you run with your new application you can re-encrypt the link again.

  • 0 in reply to Hung Bui

    Thanks for your answer and proposal 2). We will update our Bootloader following these advises.

Related

core_v2_widget.Hide()