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

Usama Aftab — Fri, 01 Mar 2019 19:01:44 GMT

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.

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

Aleksander Nowakowski — Fri, 01 Mar 2019 11:47:57 GMT

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.