NCS 2.7 with mcuboot via sysbuild
custom board with nrf52840, 2 custom applications (manufacturig and end-user)
In my application our DFU will be performed over BLE. I have enabled the SMP service with GRP_OS and GRP_IMG and Image Manager. I was testing DFU with the NRF Connect app on Android.
The update process seems to depend on the DFU managing application (nrfConnect) on the remote Bluetooth device (android phone) to complete the update sequence with an image confirm. During my test, an extended driver startup time (downloading to an external component) caused the remote Bluetooth host update to timeout. Since the process was not completed with the image confirm, mcuboot swapped images on every reset.
Luckily in my test the 2 images were significantly different (manufacturing vs end-user) and it was quit noticeable that the image was getting swapped back and forth. However this seems like a very tricky bug to discover in the field.
From my perspective relying on an external system to complete the DFU procedure is a major flaw. End-users are very unpredictable, they cannot be expected to keep their phone within range while the images are being swapped. Swapping back and forth on every reset forever doesn't ever seem like it would be an intended behavior for a typical DFU use case.
Is there a sample that demonstrates how to build a bulletproof OTA DFU, that would include handling the case where the remote Bluetooth host is not available to confirm the final firmware?