• State Verified Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 1360 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 322750
Options

nRF Connect app (Android) DFU does not perform Validation/Reset

clockis

Greetings,

We have developed a custom application based on the nRF Connect SDK (v2.1.0) which utilizes the MCUMgr for DFU (OTA) and have been performing several OTA FW updates using this feature for a while now (months) without any issues using the nRF Connect app (Android & iOS) using the 'Confirm only' option.

However today after trying to perform an OTA FW update using the nRF Connect app (Android), as usual, the update did not progress as expected. It started the update process, and uploaded the image correctly but on the last step in which the image is Validated and the device is Reset was not performed and the device remained in DFU mode. This was reproduced at least 5 other times using the nRF Connect app (Android).

(It is also worth noting that after repeating the update with the same FW image the device skipped the upload step (which is expected as the image was already present on the device) and performed the Validation and Reset steps correctly and the DFU to the target image was completed successfully and the device started the newly updated application image.)

After trying the same process using the nRF Device Manager app (Android) the process was completed successfully and the Upload,Validation and Reset was performed as expected with the device resetting, exiting DFU mode and entering the updated application successfully as expected.

This was being performed correctly on the nRF Connect app as well until now. We have made no changes in the BLE stack or the MCUMgr/DFU setup.

Were there any recent updates to the nRF Connect app (Android) that could cause this to happen on the nRF Connect app but not on the nRF Device Manager app?

Thank you and I look forward to hearing from you!

Best regards,

Stavros

Parents Reply Children
  • 0 in reply to AHaug

    Hi Andreas,

    Great! Thank you for the immediate feedback!

    It would also be useful if you have any other hints as to what differences the nRF Connect app & nRF Device Manager app have, as well as any way this could be FW related ( although that would be very strange as the MCUMgr setup as well as the BLE stack settings were not changed at all ).

    Thanks again!

    Kind regards,

    Stavros

  • 0 in reply to clockis

    Hi,

    Two questions:

    The developers wants you to verify if you've made any changes to the firmware related to OTA updates in between you firmware updates was successful with confirm only and when it required you to perform it twice (one to upload the image and one time to validate and reset device)?

    Could you also describe the complete procedure for building your FW, flashing, building new image for update up until you perform the update?
    What I want to verify with this is to double check if you've forgotten some steps that you used to do previously (for not making changes in the code or in firmware revision numbering such that you're now attempting to update your firmware with the exact same firmware that is currently running on the application)

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hello,

    I can confirm that I have not made any changes to the OTA updates anything even remotely related to the MCUMgr & SMP  well as the BLE stack and their configuration option has not been modified in the slightest ( the changes I made were for some details in the driver of an IMU sensor we use ).

    The process I use, after performing a change to the FW I need to test, is the following:

    1. Perform Pristine Build
    2. Rename & Copy the dfu_application.zip to my mobile phone ( I am giving it a very short name just to be able to distinguish the different images on my phone)
    3. Connect to the device using the nRF Connect application (Android)
    4. Press the DFU button in the upper right corner and select the image with the 'Confirm only' option selected

    I am aware that if the FW image is already present on the device it will skip the transfer step and proceed with the Validation & Reset, this is not the behavior I am referring to. I am always aware of this so this is why I always perform a pristine build for each of the FW images I use. During testing, I have three or four different images(all built with pristine builds, which means different hashes) that I rotate for testing the update so that the new image is always uploaded and the complete DFU process is performed( not just the Validation & Reset).

    I have been performing updates like these for months now, just last Friday I was updating some devices like this with no issues and wanted to test a new version so I tried updating them a second time and it started skipping the Validation & Reset steps while the nRF Connect Device Manager always performs these steps correctly with no issues at all.

    The one thing I had enabled in these last few versions of the FW for which this issue started happening was I had some Tracing enabled. More specifically the following options:

    CONFIG_SEGGER_SYSTEMVIEW=y
CONFIG_TRACING=y
CONFIG_TRACING_THREAD_STACK_SIZE=8192
CONFIG_TRACING_BUFFER_SIZE=8192
CONFIG_RAM_TRACING_BUFFER_SIZE=8192
CONFIG_TRACING_CMD_BUFFER_SIZE=64

    Could this cause an issue with the FW update?

    I want to still emphasize that even though the issue was present with the typical update procedure I have used for months ( utilizing the nRF Connect app ) the nRF Connect Device Manager app always performed the updates correctly 100% of the time. I have reproduced this issue several times and have confirmed that for the same images, the first app skips the last and crucial steps (Validation & Reset) and the second app does not.

    Thank you very much for your support and immediate response and I look forward to hearing from you!

    Kind regards,

    Stavros

  • 0 in reply to clockis

    Hi Stavros,

    Apologies for the long response time, I have been out of office since my last inquiry

    Could you verify what Nowakowski (who's one of the devs behind the apps) asks and we'll look further into it if it's something else causing hte issue?

    Kind regards,
    Andreas

  • +1 in reply to clockis

    After a lot of testing and validating the cause of this issue it was found that the problem was including the Tracing configuration options listed in my previous comment.

    More specifically:

    CONFIG_SEGGER_SYSTEMVIEW=y
CONFIG_TRACING=y
CONFIG_TRACING_THREAD_STACK_SIZE=8192
CONFIG_TRACING_BUFFER_SIZE=8192
CONFIG_RAM_TRACING_BUFFER_SIZE=8192
CONFIG_TRACING_CMD_BUFFER_SIZE=64

    After removing these the DFU process (I always use the 'Confirm only' option) returned to its expected behavior and everything worked as it did previously. 

    Thank you very much for your support. This ticket can now be closed.

Related
Terms of service