• State Verified Answer
  • Replies 22 replies
  • Subscribers 70 subscribers
  • Views 4289 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

Parents
  • 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

    Hi all,

    I use Xiaomi Mi9T MIUI 12.1.4 (Android  11). I also have Iphone 6s, but as I wrote, there is a restiction of BLE throughput from iOS, which leads to another error. I guess I could figure out how to fix it, but I can't work again these days :-(

  • 0 in reply to AHaug

    I am testing this on a Google Pixel 4 as well as a 2019 iPad - not the pro version.

    Thanks for the input. If it could be device specific, have there been any known fixes for this?

  • 0 in reply to Robert de Brum
    Robert de Brum said:
    Thanks for the input. If it could be device specific, have there been any known fixes for this?

    I am working on getting a larger sample size than us 3 to see if it is device specific. If it indicates that it is so, then I'll investigate it closer and examine if there are any possible fixes.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi,

    I've been out of office due to the christmas holidays here in Norway, but in the meanwhile I've had some colleagues of mine perform some tests and see if they could reproduce the errors on their end. Unfortunately it all seemed to succeed on their ends. 

    Could you attempt to do the following:

    1. Build and flash a clean version of https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340/mcuboot_smp_ble_simultaneous
      1. If you have modified the SDK at any point, please try with a clean version of NCS.
    2. Perform DFU with the pre-built zips found in the folder "dfu_zips" in https://github.com/aHaugl/NCS_Simult_DFU_test in sequence or try to follow the steps in the repository yourselves

    If you still observe the same issues, please state so here and I'll follow up on them.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hello,

    Thanks so much for your time and efforts on this. I was able to successfully DFU both cores per the sample via Google Pixel 4.

    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.

    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.

Reply
  • 0 in reply to AHaug

    Hello,

    Thanks so much for your time and efforts on this. I was able to successfully DFU both cores per the sample via Google Pixel 4.

    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.

    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.

Children
  • 0 in reply to Robert de Brum
    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

Related