Client automatically reconnects to server after OTA DFU

RE: Client automatically reconnects to server after OTA DFU

Mike Austin (LPI) — Thu, 07 Jul 2022 06:12:58 GMT

[quote userid="3284" url="~/f/nordic-q-a/89502/client-automatically-reconnects-to-server-after-ota-dfu/375919"]The reset command from Mcumgr should do the same. It should reboot the device after gracefully disconnecting. Perhaps check why it doesn't work as intended?[/quote]

We can see that reset command being issued my the Mcumgr with both the devices, and this then restarts our device and it then beings advertising. But for some reason on the 12/12Pro, the phone would then reconnect and the only way for us to get our device to disconnect was to force it to stop advertising (we enable/disable this via a GPIO)

Much as I'd like to understand why, the commerical realities of getting product to market dictate that "if you've got something that works, move on to the next issue"

Cheers,

Mike

RE: Client automatically reconnects to server after OTA DFU

Aleksander Nowakowski — Thu, 07 Jul 2022 06:01:53 GMT

The reset command from Mcumgr should do the same. It should reboot the device after gracefully disconnecting. Perhaps check why it doesn't work as intended?

RE: Client automatically reconnects to server after OTA DFU

Mike Austin (LPI) — Thu, 07 Jul 2022 05:12:01 GMT

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

RE: Client automatically reconnects to server after OTA DFU

Hung Bui — Tue, 05 Jul 2022 09:34:47 GMT

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.

RE: Client automatically reconnects to server after OTA DFU

Mike Austin (LPI) — Sat, 02 Jul 2022 22:47:49 GMT

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

RE: Client automatically reconnects to server after OTA DFU

Aleksander Nowakowski — Sat, 02 Jul 2022 06:30:14 GMT

[quote userid="109035" url="~/f/nordic-q-a/89502/client-automatically-reconnects-to-server-after-ota-dfu/374997"]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.[/quote]

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?

RE: Client automatically reconnects to server after OTA DFU

Aleksander Nowakowski — Sat, 02 Jul 2022 06:22:51 GMT

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.

[quote userid="109035" url="~/f/nordic-q-a/89502/client-automatically-reconnects-to-server-after-ota-dfu"]But because it remains connected after the OTA DFU, things get all locked up.[/quote]

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.

RE: Client automatically reconnects to server after OTA DFU

Hung Bui — Fri, 01 Jul 2022 07:14:22 GMT

Thanks Mike.
I think this is something we can fix in the iOS DFU library. I assume you have the same problem when you test with nRF DFU app or nRF Toolbox app , correct ?
I will report your observation to the app team and will let you know when we have any update.

RE: Client automatically reconnects to server after OTA DFU

Mike Austin (LPI) — Fri, 01 Jul 2022 06:14:26 GMT

Hi Hung,

Thanks.

So, in "normal" operation, the device is advertising, but the App doesn't try and connect. It just grabs the scan response data and updates its info that way. The only time it will connect is to do a DFU.

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.

But after the DFU and with my custom App forcing the software reset, I would have thought the Peripheral would disconnect. If I do a reset on the DK, it certainly forces the disconnect. But having my App force the reset, it doesn't seem to.

I grab the vallue of RESETREAS when it first boots up, and not surprisingly, when the App resets the device, I see RESETREAS = 0x04, which corresponds to the Software Reset (SREQ). My code then sets up Bluetooth and starts advertising. The Client then connects, even though I don't want it to.

If I do a RESETPIN reset via the button on my DK at this point, then the device will go through the Bluetooth start up and start advertising, but will not reconnect to the Central.

The brute force method at this point might well be that my App needs to write to my "disconnect" characteristic to force a disconnect.

Cheers,

Mike

RE: Client automatically reconnects to server after OTA DFU

Hung Bui — Thu, 30 Jun 2022 09:32:07 GMT

Hi Mike,

I will check with the app team to see if there is any solution.

But could you let me know, if you turn on the device (in normal operation) close to the phone, would they automatically connect ?
As far as I know if a paired device is in range, the phone may just re-connect to it automatically.