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

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

Parents
  • I believe I found why this issue happens.

    After many trials I took another NRF5340DK (fortunately I have two), flashed it with the same firmware - and updating works as it should be. Initially I decided that my first DK is broken, but it's not...

    This sample uses external qspi flash for storing update images... I did full qspi erase with

    nrfjprog --qspieraseall

    And now updating of my first DK also works as expected.

    I believe at one moment the external qspi flash was written with wrong data (I tested interruption of the updating process with power off). After that the upgrading functionality became broken

    This leads me to a question: is it possible to handle such situation in any way? Maybe we should make full erase of an external flash before each DFU procedure? Or maybe it's possible to erase qspi with some MCUMGR command?

Reply
  • I believe I found why this issue happens.

    After many trials I took another NRF5340DK (fortunately I have two), flashed it with the same firmware - and updating works as it should be. Initially I decided that my first DK is broken, but it's not...

    This sample uses external qspi flash for storing update images... I did full qspi erase with

    nrfjprog --qspieraseall

    And now updating of my first DK also works as expected.

    I believe at one moment the external qspi flash was written with wrong data (I tested interruption of the updating process with power off). After that the upgrading functionality became broken

    This leads me to a question: is it possible to handle such situation in any way? Maybe we should make full erase of an external flash before each DFU procedure? Or maybe it's possible to erase qspi with some MCUMGR command?

Children
  • Hi, 

    Apologies for the very late response. I have been out of office due to circumstances I did not plan for when I picked up your case, and I will be until Friday this week.

    A quick (and temporary) answer to your question: I believe there should be a config or something similar that will allow you to erase what is on the external flash before doing the DFU, and my best guess (with the resources I have at hand at this given point in time) is that you will have to erase what is on the flash before doing the DFU. Before I can verify this 100% I need to consult with some of my colleagues, and I will do my best to get a reply that answers and verifies your findings regarding your issue on Friday, no later than Monday. 

    I hope that this prolonged response time has not caused too many issues for you,

    Kind regards,
    Andreas

  • Thank you Andreas, I'm looking for you reply

  • Hi, 

    We've spent some time trying to reproduce the issue you're describing, to isolate if there is a bug in the sample or in the SDK, without any luck. I've tried with several boards and versions of NCS and every combination seems to work out of the box when following the guide. I know you've stated that you've only added some logging functionality, but could you state all the changes you've done so I can exclude if those changes are the issue?

    Is the issue present if you try to do DFU without the external flash?

    This is the result whenever I follow the steps in the guide: 
    1) The initial build that is flashed,
    In between 1-2: Make changes to main.c, build and upload the zip to your mobile device, and perform DFU with nRF Connect for Mobile
    2) nrfjprog --reset to restart the device
    3) Observe the new output

    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.

    Do you generate a new build with changes in between the initial flash + erase and before you perform DFU with the application zip? If this is not the case, and the firmware is the same in the update zip as in the firmware on the device, then the reason it is working is because the hash of the firmware image is identical in those two images, and mcuboot detects this and skips the update since the hashes are identical.


    Sergey said:

    After many trials I took another NRF5340DK (fortunately I have two), flashed it with the same firmware - and updating works as it should be. Initially I decided that my first DK is broken, but it's not...

    Could you check which revisions the DKs are? It should be written on a sticker on the device (for instance 0.11.0). 

    Kind regards,
    Andreas

  • Hi Andreas,

    sorry for late reply - I'm in Ukraine, and it's complicated to work these days (with electricity for 4-16 hours per a day)

    Is the issue present if you try to do DFU without the external flash?

    My main goal is to achieve DFU with encrypted app image (I described it here devzone.nordicsemi.com/.../how-to-encrypt-fw-for-mcuboot-image-update ) - now it's the second attempt :-) I wish I could do it early, but...

    It seems encrypted update works only when simultaneous net core/app core DFU is enabled. Thus if to do it without external FLASH, I have to create many partitions in main flash memory, what dramatically reduces available memory for the app image. Thus for me it's not the case, I haven't tried simultaneous update without external flash

    Anyway, this issue was detected without any encryption, I used the example from github without modifications. Maybe some data in external flash from previous experiments has impact?

    Do you generate a new build with changes in between the initial flash + erase and before you perform DFU with the application zip? If this is not the case, and the firmware is the same in the update zip as in the firmware on the device, then the reason it is working

    I tried both cases. If I try to update with initial firmware (i.e. zip as in the firmware on the device) - at least OTA process is starting and works, the firmware is being uploaded from mobile device to the DK, regardless the next MCUBOOT steps. In any words - I can upload the firmware

    The main problem was - if I generate a new build with any changes (logs, or just change version number in config), I see "Starting DFU" on the mobile device screen, and then it immediately disconnects. I.e. firmware uploading even doesn't start. I would say that it's a bug in mobile app, but why it works after full erase of SPI FLASH?

    Could you check which revisions the DKs are? It should be written on a sticker on the device (for instance 0.11.0).

    My first DK is 0.11.0. The second is 1.0.0

  • Hi,

    Sergey said:
    sorry for late reply - I'm in Ukraine, and it's complicated to work these days (with electricity for 4-16 hours per a day)

    No worries about the reply time, and your situation is very understandable. I'm here to give technical support whenever a reply/question comes in as long as the issue is unresolved.

    Thank you for supplying this information as well. I will consult with Einar (who supported you in the ticket you created) and Sigurd (who has created the 5340DFU sample you've based your application on) and see if we can find a solution.

    Sergey said:
    Is the issue present if you try to do DFU without the external flash?

    It looks like I had misunderstood the sample you were testing from Sigurd, as the simultanous dfu sample for the 5340 is indeed using external flash, so there is no need to verify if the issue is present without external flash.

    Sergey said:
    Anyway, this issue was detected without any encryption, I used the example from github without modifications. Maybe some data in external flash from previous experiments has impact?

    I will do an experiment to see if I can recreate the issue by adding something to the EF and attempting DFU without clearing the contents. This is just speculation, but there might be something protected on the location where the update image is supposed to go that causes the issue or that mcuboot that initializes the DFU procedure are looking at the wrong address relative to where the image is.

    I'll get back to with some results as soon as I get them (hopefully by tomorrow)

    Kind regards,
    Andreas

Related