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

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

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

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

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

Children
No Data
Related