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

nRF Loader App on IOS failes if device is paired

Adrian Eggenberger

Hi

We had some problems updating our devices with the nRF Loader App on IOS. After selecting the device in DFU mode the App hangs and aborts with a Bluetooth error after a timeout. As we already had tested, that the same App can update our devices we were quite confused. A lot of tests with various versions of our bootloader code didn't show a solution.

At the end we found out what causes the problem. If the device is paired with the IOS device the App hangs. When the the pairing is removed the App works as expected.

BR Adrian

  • 0

    Unfortunately this is to be expected with the bootloader as currently implemented in the SDK.

    This is a consequence of the bootloader being a completely separate application. Normally, if the main application on a chip does bond, it will store its bonding information in its own part of the flash. This bonding information is also tied to the main application's GATT Table layout. Since the bootloader is currently a separate application, it doesn't have any way to know where any bonding information is stored, and it will also have a different GATT Table layout. It can hence not use the same bonding inforation.

    However, for the peer device, the device looks exactly the same (has the same address) no matter if it runs the main application or the bootloader. It will therefore rightfully expect that the bootloader also knows about the bonding information the peer device have exchanged with the main application, and when the bootloader doesn't, things fail.

    I'd therefore suggest that you take the bootloader as delivered in the SDK and integrate the DFU service and flash writing in your regular application. In this way, while running the main application and having access to the normal bond information, the a new binary image can be received and written to the swap bank of the flash. The only thing left to do in the bootloader is then to do the actual data copying from the swap bank to the main bank of flash.

    The final gotcha is however that bonding information as mentioned above is tied to GATT Table layout. If the new binary changes the GATT Table (adds a new service, removes a service), the system attributes of the old bonding information is no longer valid, and you may get trouble. However, as long as you don't change the GATT table, it should be perfectly possible to make this work by following the above suggestion.

  • 0 in reply to Ole Morten

    Your answer make perfectly sense, but it's not really good news... Adding some parts of the DFU to the normal application would be possible, but i prefer not to use it. Do you konw if it's possible that a IOS app can evaluate if a devie is paired or not? Can the app remove the device from the paired list? That would allow us to have our own app that removed a pairing to the device to update.

  • 0 in reply to Ole Morten

    No, security and bonding is handled completely transparent for iOS apps, and there is no way an app can know whether a device is bonded or not, nor delete the bond information. This must be done by a user, through the settings menu.

    The only thing I can think of, if you absolutely need to have the bootloader completely separate is to change the address in bootloader mode. However, this would require the iOS app to do a scan for new devices instead of issuing a connect to an already known one, which may in some cases be a problem. I therefore do think you're better off doing as I suggested above.

  • 0 in reply to Ole Morten

    Hello Ole,

    is this answer still valid, now that SDK6.1 has taken the DeviceManager out of the experimental phase? Also, it seems to me that the "Application with DFU restart" example at devzone.nordicsemi.com/.../a00076.html is not addressing this issue; is that correct or am I missing something here?

    I am trying to follow your suggestion and integrate the DFU code with our app, but the RAM usage is a big problem (the DFU uses hci_mem_pool, which in turn uses 3.2K RAM just for TX/RX queues). I tried reducing the queues allocation in hci_mem_pool_internal.h, but it seems to heavily affect reliability (packages arrive faster than they can be written and the mem_pool gets full).

Related