NRF5340 simultaneous multi-image FOTA DFU: works with initial firmware update, but can't upload any revised new version

[Sergey]

I'm trying to use simultaneous FOTA update of both cores with NRF5340DK, and there is a strange behavior with any update with modification - the uploading from mobile app just doesn't start. My setup:

1) NRF5340DK

2) mobile phone with Android NRF connect app for updating via Bluetooth

3) sample project https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340/mcuboot_smp_ble_simultaneous  compiled with NRF Connect SDK 2.1.2

After firmware initial flashing with "west flash --force --erase" the firmware works as expected. I'm able to make DFU via Bluetooth with dfu_application.zip from build/zephyr folder - and I can do it multiple times without problems.

But if I change something in firmware (for example a log message), compile a new build and try to make DFU with this the new dfu_application.zip - uploading doesn't start. The NRF Connect Android app immediately disconnects after "Starting DFU". 

What I'm doing wrong? How to make DFU with a modified firmware, and why it works only with initial firmware

[AHaug]

Robert de Brum said:

I think that the first issue that I discovered was that I did not successfully build the sample with ncs version 2.1.2 - I was still using 2.0.0.

A version conflict could explain the issue. The sample should be usable for NCS v2.0.0 up to the latest v2.1.x, and with v2.2.0 it yields some errors due to header changes (not checked what issues yet). So also note that this sample is something that is currently not a official sample we support in the SDK so in its current state it will not be maintained, but rather a sample used as suggestions/illustrations for developers to use in their own applications.

Robert de Brum said:

The other issue I am discovering is that while the pixel will successfully DFU every time, the iPad fails to do so - I was only able to DFU once with the iPad, from dfu_zips/3/dfu_application.zip to dfu_zips/1/dfu_application.zip.

This sounds strange. What do you observe when testing the pre-built dfu_zips on your iPad/where does it fail?

What we observerd when performing the test with an iOS phone was that the finalizing of the transfer did not show up in the app, but we saw the new firmware when observing the output in a terminal after the app timed out and restarting the device. Could it be the same case with the app version on the iPad?

Kind regards,
Andreas

[Sergey]

Hi,

I've just tested with my phone (the same phone which I used with experienced issue). It seems all works as expected with your pre-built zip files. 

I will work with my tests later, and if I will experience my issue, I will report here once again. Can't imagine why it happened...

[AHaug]

Glad to hear that you got it to work with the samples I built, and I must say it is still strange to me that your builds did not work. I think we can conclude that it is most likely either a version conflict or that something in the SDK is not identical to the pristine SDK I were using when. Let me know if and when you have the possibility to test with a fresh install of NCS!

One pit fall I think that could have occurred is the order of building the new firmware that could've caused the errors. You can follow the "manual" steps in the test repository I created to see if you've included what you need to for instance add logging to the application.

Please let me know if you have any additional questions to this topic and/or if you feel that we can close the case for now! 

Kind regards,
Andreas

[Robert de Brum]

Hello,

I am still working on this for now, but iOS does not work as robustly as the Pixel does yet.

When I try to DFU from my iPad 9th generation, I can successfully DFU once, but then any subsequent DFU fails. Unfortunately, the plans for the product I am working on require iOS as the main platform for the mobile app that will interface with my firmware on the nrf5340. There will not be an android app for some time, and so getting this to work on iOS is a big priority for me and my customer.

Note some of these images that occur when I use nrfConnect to DFU.

This sequence happens on a successful DFU with the 9th Gen iPad. Notice the final images says that the DFU failed, but on reset, the device is running the new image.

After this "successful" DFU, I will experience this on any subsequent DFU's. The file does not get uploaded and so resetting the device does not prove that the DFU worked.

On the Pixel, I can DFU any of the .zip files from your samples, in any order, at any time.

Along these lines, I just opened another ticket in which I am concerned with importing this sample and it's multi-image capability into my firmware project. I am posting the ticket link in case there is any parallel thought or discussion that should be had. devzone.nordicsemi.com/.../multi-image-dfu-project-structure

[AHaug]

Hi,

I might be assigned to your new case later today, but in the meanwhile I'll answer you here. We had a similar situation when testing the test-repository on an iOS phone, where the confirmation request timed out after transferring the update zip, but after rebooting the nRF5340 device that received the image we could see that the new firmware were running and that it had not reverted back to the original image.

So a couple of questions to start with so we can weed out the "simplest" errors:

1. Are you seeing the initial build, or the updated build after rebooting the nRF device after the image has been sent and the request has timed out?
2. If you're seeing the initial build, can you verify that you're not using the dfu_application zip that corresponds to the same build that is on the initial device?
   1. If you're using dfu_application generated when building the initial build, or a build without any changes to the code, then the bootloader will not do anything as these applications are identical
   2. If you're using dfu_application generated with a second build, perform dfu and verify that you see the changes you've done to the code in the second build, then attempt to do dfu once more with the same dfu_application generated with the second build (i.e. use the same application image twice in a row), then you will see the same behavior as in item 2a.

Let me know about these question, and we'll see if we should discuss the seemingly iOS related issue in the other case as we're starting to overstep the (soft) "one-topic-per-case-boundary" if it's not related to abovementioned questions. It is a possibility that there could be an issue with the iOS version of the app.

Kind regards,
Andreas