• State Verified Answer
  • Replies 22 replies
  • Subscribers 70 subscribers
  • Views 4285 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 298741
Options

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

  • 0

    Just tried with iOS (iPhone 6S) - at least now I have an error message "Insufficient MTU: 182". But I believe this is related to iOS restrictions, not to the main problem

  • 0

    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?

  • 0 in reply to Sergey

    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

  • 0 in reply to AHaug

    Thank you Andreas, I'm looking for you reply

  • 0 in reply to Sergey

    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

Related