Client automatically reconnects to server after OTA DFU

I'm trying to implement OTA DFU in our custom App with our nRF52832 acting as the device to be upgraded.  Everything seems to work OK in that:

1. New image uploads to the device

2. App resets the device to transfer new image into correct area

3. App does a check to ensure the new image is OK, then confirms this with the device

4. App forces another software reset on the device

At this point, the device should start advertising again.  But for some reason it stays connected to the client.  I'm trying to work out how to prevent this happening, primarily as my App is only scanning for devices and grabbing the scan response data to update its info.  It only needs to connect when its going to do an OTA DFU.  But because it remains connected after the OTA DFU, things get all locked up.

Not sure if this needs to be driven from the client or the server side.  Client is an iOS device running our custom App.  I am also using the CTS on the server, so client and server are paired at some point.  I believe this is a requirement by Apple for devices to access CTS on an iOS device.

Any ideas how I can ensure that the client doesn't automatically reconnect to the server after the final reset at the completion of the OTA DFU?

Cheers,

Mike

Parents
  • OK, so what we were able to ascertain is that it seemed to be device specific.  We are testing with two different devices (based on what our dev team have as their own handsets basically)

    1. iPhone 7, running iOS 15.5 - this would successfully disconnect from the device at the completion of the DFU

    2. iPhone 12/12Pro running iOS 15.5 - this would NOT disconnect from the device once the DFU had completed, even after issuing multiple software reset commands.

    So, we've resorted to a brute force method, and have a service/characteristic that we write to at the end of the DFU, that forces the device to disconnect the connection itself.  Seems to work on both the devices listed above.

    Not really sure why different devices behave differently, but we've got a solution that works

    Cheers,

    Mike

Reply
  • OK, so what we were able to ascertain is that it seemed to be device specific.  We are testing with two different devices (based on what our dev team have as their own handsets basically)

    1. iPhone 7, running iOS 15.5 - this would successfully disconnect from the device at the completion of the DFU

    2. iPhone 12/12Pro running iOS 15.5 - this would NOT disconnect from the device once the DFU had completed, even after issuing multiple software reset commands.

    So, we've resorted to a brute force method, and have a service/characteristic that we write to at the end of the DFU, that forces the device to disconnect the connection itself.  Seems to work on both the devices listed above.

    Not really sure why different devices behave differently, but we've got a solution that works

    Cheers,

    Mike

Children
Related