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
  • Hello  

    I believe that you're using nRF5 SDK, not NCS, therefore OTA over Secure or Legacy DFU. Could you write which SDK version?

    Either way, in both legacy and secure dfu, the update is performed by the dfu bootloader. The last command sent after upload is complete triggers device restart, initiated from the device side. Mobile dfu libraries report succees only after the device disconnects. The device then switches back to application mode.

    As I understand, your device has Current Time Service (CTS). iOS it a requirement for the project? It's not required by iOS, it exposes it's own CTS service, but there's no need to use it.

    Are you using pairing or bonding? I believe, after the restart it's starting direct advertising which may triggers automatic reconnection from the phone. iOS can support CTS service natively, so may hold the connection writing any app running.

    But because it remains connected after the OTA DFU, things get all locked up.

    Is it connected to the bootloader, or your custom firmware?

    Also, the mobile dfu libs are generating logs. It would be very helpful to see them. I believe that the dfu operation ends with a restart and it is the advertising initiated by firmware that triggers the phone to reconnect, but logs could prove me being wrong.

Reply
  • Hello  

    I believe that you're using nRF5 SDK, not NCS, therefore OTA over Secure or Legacy DFU. Could you write which SDK version?

    Either way, in both legacy and secure dfu, the update is performed by the dfu bootloader. The last command sent after upload is complete triggers device restart, initiated from the device side. Mobile dfu libraries report succees only after the device disconnects. The device then switches back to application mode.

    As I understand, your device has Current Time Service (CTS). iOS it a requirement for the project? It's not required by iOS, it exposes it's own CTS service, but there's no need to use it.

    Are you using pairing or bonding? I believe, after the restart it's starting direct advertising which may triggers automatic reconnection from the phone. iOS can support CTS service natively, so may hold the connection writing any app running.

    But because it remains connected after the OTA DFU, things get all locked up.

    Is it connected to the bootloader, or your custom firmware?

    Also, the mobile dfu libs are generating logs. It would be very helpful to see them. I believe that the dfu operation ends with a restart and it is the advertising initiated by firmware that triggers the phone to reconnect, but logs could prove me being wrong.

Children
No Data
Related