nrf52 DFU package with SD+BL+APPS fails to reconnect on iOS nrfToolbox after updating SD+BL

[Francis]

We're seeing an issue where a dfu package containing SD+BL+Apps gets stuck on iOS nrfToolbox during DFU process after it updated the first part 1/2, which is BL+SD. The same dfu package works on the Android nrfToolbox DFU, it's able to reconnect just fine to update the 2nd part, apps.

last part of iOS log after part 1/2: Application: Upload completed in 158.17 seconds Debug: [Callback] Central Manager did disconnect peripheral Info: Disconnected by the remote device Verbose: Scanning for the DFU Bootloader... <-- stuck here

I've confirmed that the target device did reboot back to DFU and advertises just fine. Again, on Android this usecase works just fine with the same dfu package containing SD+BL+Apps.

[Aleksander Nowakowski]

Hi Francis,

I think the problem you have is related to how iOS DFU Libary reconnects to the 'new' bootloader after SD+BL was flashed. In the current version of Secure DFU, and in some cases in Legacy DFU, the new bootloader will advertise with address +1, comparing to what the device in app mode had. The reason for that is that when SD+BL is flashed, the old app is removed and the new bootloader doesn't know if the previous app had Service Changed characteristics or bonding so it must change the address so on device that cache services it can be correctly handled.

On Android we can just rely on the device address, add +1 to it and look for this new address. On iOS the API does not expose devices addresses, so we have to do some tricks. The DFUPeripheralSelector is used instead. The default one selects a first device having DFU Service UUID in the advertisement packet. If your bootloader advertises with different data you have to override it and set to the DFUServiceInitiator as described in the inline docs. However, this DFUPeripheralSelector, in the current version, will connect to the first device found having the required service UUID so if you have a bunch of devices in DFU mode a random one can be actually updated. A solution for this will come in SDK 14 and 14.1, I suppose, or somewhere in not that far future.

So, TLDR, the selector scans until it finds a device advertising with something that return true. I hope it solves your issue.