CentralManagerDelegate's didConnect doesn't get called after a dfuError occurs during DFU Process.

[Usama Aftab]

I have a complete implementation of OTA DFU where iOS app performs a DFU to a nRF based BT Device. Now i am implementing a fix for the situation where:

• During DFU, if peripheral's power turns off.

The desired behavior is when the disconnection happens, Central (iOS app) should wait 10 seconds and performs another scan. If the device is broadcasting (in application mode), automatically connect and resume the firmware update process.

Now for that, i am checking if an unexpected disconnection happens at dfuError method of DFUServiceDelegate. dfuError triggers properly, I then rescan for peripherals in 10 seconds and try to connect. I manage to connect to the peripheral (as i see it is not broadcasting any longer) but the didConnect method of Central Manager Delegate doesn't get called.

My question is if we need to do something special to clear the central manager or DFUServiceInitiator after a dfuError occurs? It seems like even after dfuError (upon disconnection), iOS SDK thinks that the device is still connected. That is why didConnect method of CentralManagerDelegate doesn't get called.

Any thoughts?

[Aleksander Nowakowski]

Hello,

If you are using the now-deprecated init of DfuServiceInitiator: https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library/blob/422caf59d89f1ded7e9f403f17a5ea863b6b40ff/iOSDFULibrary/Classes/Implementation/DFUServiceInitiator.swift#L227 you need to restore your CBCentralManager's delegate when DFU is complete, an error happen, or has been aborted. With the new init method below this is no longer required and the library is using it's own CBCentralManager instance, so no delegates are being stolen from the app.

If you see that after dfuError your device started advertising it mush have disconnected. If you see it no longer advertising after you reconnect, it must have reconnected. Right now, the only reason that comes to my mind that could cause you not getting didConnect is the one I wrote above, with the delegate not being set again to CBCentralManager. I hope I'm right. Consider updating DFU library to 4.2.2 and using the new init method instead.

If you are already using it, try reassigning delegates just to be sure. You may also release all references to the old DFU initiator and controller to allow those object to be released.

I'm about to release version 4.3.0 of the library today, but no changes there will actually have any impact on what you experience.

[Usama Aftab]

It is exactly what it was. After the DFUServiceInitiator process finishes or gets an error, central manager was still in the dirty state. I have to re-attach the delegate and then everything worked fine.

I will update my library to 4.3.0.

Thanks for the help.