Add possibility to run CONFIRM step after DFU when device becomes present again (advertising after reboot)

[gte1]

Normally the swap time setting defines when the CONFIRM step is performed. If the device starts advertising again before that timeout, then allow the CONFIRM step to be executed.

(if decided to implement, the IOS version should be updated too)

[philips77]

Sorry, I don't get it.

In Test & Confirm mode the library will:

1. upload,
2. send TEST command,
3. send RESET command,
4. wait "swap time",
5. try to connect,
6. send CONFIRM command,
7. Report success.

What would you like to change here? What is your desired path?

[gte1]

4. wait "swap time" or detect that device has rebooted (device starts advertising again), whichever comes first

[philips77]

The device usually reboots immediately after RESET is sent. Then, if the bootloader is in Swap mode, it will move images from secondary to primary partition which will take time. For nRF52840 it's around 15+ seconds, depending on the image size. The swap time should be measured for given device and set before updating, so that "try to connect" does not timeout. After swap is complete the new image is booted. I understand that by "rebooted" you mean this whole process.

To measure when a device is ready to reconnect the library would have to scan for it. This would add a lot of complications on Android side. There are Location permissions that have to be granted on some Android versions, Location service enabled, Nearby permission, etc. And this is only for Test & Confirm mode.
Having customizable "swap time" seems OK, as the "try to connect" has ca. 30 sec timeout, so you may set swap time for less than really needed and reconnection should be immediate when ready.

Also, NCS 2.5 added "Direct XIP" bootloader mode. This requires changing the McuBoot to one which would support it, but this means no swap at all and reboot is immediate.

[gte1]

I see your point on the complexity of implementing this.

We use ncs 2.5 now, but have devices in the field that started with ncs 2.2, and some with ncs 2.4.
Those older devices does not have mcuboot with Direct XIP, so we will have to keep using the swap method.

[ksidirop-laerdal]

Sorry, I don't get it.

In Test & Confirm mode the library will:

1. upload,

2. send TEST command,

3. send RESET command,

4. wait "swap time",

5. try to connect,

6. send CONFIRM command,

7. Report success.

What would you like to change here? What is your desired path?

@philips77 Just thinking out loud off the top of my head - just bare with me:

What if we try to connect + send the "confirm" command preemptively every few seconds and see if it has any effect - if it doesn't then wait a few more seconds and retry connect+sending "confirm" until it actually succeeds.

This way we won't have to wait for the full-swap time duration just to try sending "confirm" once at the very end and the code-changes will essentially enrich a mechanism which is already in place - no need for fancy stuff with permissions etc.

Might be missing something - Let me know what you think.

[philips77]

That could work, yes, but I have 2 questions.

1. Why do you need this feature? Do you have different devices with different swap times? Does your device sometimes requires more, sometimes less time to swap? Is it not possible to estimate approximate swap time (connection timeouts in 30 seconds)?
2. Your suggested approach would require adding some timeout property to finally give up those connections.

[gte1]

I can answer this (since I am a collegue to @ksidirop-laerdal):

1. Our device might get increased swap time as new features are added and the firmware image grows. But the main reason is that at startup of a newly uploaded firmware version, we sometimes have to do some housekeeping before starting the BLE services. (we use littlefs, which sometimes has high latencies, sometimes tens of seconds if it decides to do garbage collection etc.). So to make sure that we get the uploaded image confirmed, we would have to set an unecessarily high swap time.
2. Could that timeout just be the swap timeout setting?

[philips77]

OK, thanks for explanation. I'll discuss with my colleagues.