Client automatically reconnects to server after OTA DFU

[Mike Austin (LPI)]

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

[Aleksander Nowakowski]

Mike Austin (LPI) said:

I do notice that if I connect to the device using any other iOS BLE app (nRF Connect, LightBlue, etc) then when I hit the "disconnect" button on those apps, the Central doesn't actually disconnect from Peripheral.  I actually had to create a characteristic that I have to write to in order to force the disconnection from those Apps.  This might be something to do with iOS - I'm not sure.

This is expected behavior. A device on both Android and iOS can be connected by multiple apps or multiple clients in each app. The physical Le connection is terminated only when the last virtual connection is discontented. A virtual connection may also be held by the system, if is supports the service, e.g. HID, or, in case of iOS, perhaps CTS service. A command to trigger disconnection from the device side is indeed the only solution for this use case.

However, I understand that it is the automatic reconnection, not lack of disconnection, that's the root cause. Try disabling direct advertising, or the CTS service, if you don't need it.

If connection is only for dfu, why do you have pairing/bonding in the first place?

[Mike Austin (LPI)]

Hi Aleksander,

Thanks for that explanation - makes sense

We're using NCS V1.9.1 to do our development.

I'll follow up your other post with some logs from the nRF Connect App.  That App actually works, in that I don't get the automatic reconnect at the completion of the DFU (but it does hold the connection even if I press the 'disconnect' button in that App).  Its our custom App that is the issue, so maybe I need to get the App developers to dig a bit deeper into what their App is doing at the conclusion of the DFU

I am using CTS so that I can update the time in my on-board RTC anytime there is a connection to the device via our App.  We time stamp events as they occur, and so want to ensure that the RTC is as close to the correct time as possible.  It also helps us set up the RTC during production.  As I understand it, pairing/bonding is a requirement of iOS to use the CTS.  I'd prefer not to have to pair/bond if I didn't need to.

Our device spends most of its time in System OFF mode.  An event on a GPIO triggers it out of this mode, it grabs some details, stores some info into NVS, then goes back into System OFF.  That's probably 99.9% of its time.

If someone wants to grab the information the device has stored, they trigger it out of System OFF via a different GPIO input, and whilst this GPIO input remains active, the device is advertising with data in the scan response packet indicating details on the events.  Our App picks this info up and displays it.  It also grabs the information stored in NVS and sends this to a database so we can collect all the information from the various devices.  If there is a firmware update available, then this can also be completed via our App whilst the device is advertising.  Its this part of the device's operation we're having issues with.  Our App developers needed the device to restart advertising after the DFU, so our App can reconnect and confirm that the DFU was successful.  After the App has confirmed this, it resets the device a second time.  The device will then restart advertising as the appropriate GPIO is still being held active.  Its at this point that our iOS device reconnects, when we don't want it to

Cheers,

Mike

[Hung Bui]

Hi Mike, 
I think the combination of Directed advertising + bonded = auto reconnection. 
So if you disable directed advertising right after the new image is running it should be able to avoid reconnecting. 

Actively request a disconnection when an unwanted connection happens is a good failsafe solution in my opinion. 

Another option is to switch between different addresses. When you don't want to be connected or bonded you use a different advertising address. And when you want to be connected and bonded you return to the original address.