• State Not Answered
  • Replies 16 replies
  • Subscribers 73 subscribers
  • Views 342 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 341346
Options

After upgrading mcuboot, the device crashes upon power-up

Carter

hi,

  After upgrading mcuboot from NCS 2.6.1 to NCS 2.9.0, the upgrade file is downloaded, and the device restarts and runs normally. The mcuboot version number and active slot are updated as expected. However, when the device is powered off and then powered on again, it fails to work properly, almost as if it has crashed. What could be the cause of this issue?

In NCS 2.6.1, the default value of CONFIG_PM_PARTITION_SIZE_MCUBOOT is 0xc000, while in NCS 2.9.0, the default value is 0xbe00. A bug related to the MCUboot partition size was fixed on October 24, 2024. Could this bug have affected the upgrade failure?

Link:Fix MCUboot partition sizes

Parents
  • 0

    Hi,

    In NCS 2.6.1, the default value of CONFIG_PM_PARTITION_SIZE_MCUBOOT is 0xc000, while in NCS 2.9.0, the default value is 0xbe00. A bug related to the MCUboot partition size was fixed on October 24, 2024. Could this bug have affected the upgrade failure?

    Generally, you need to follow the Static partitioning requirement. Im not 100% sure since it is just the headers in this case.

    But try to copy build/partitions.yml into pm_static.yml and then build the project for v2.9.0. Does DFU work then?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    I tried copying build/partitions.yml into pm_static.yml.After upgrading mcuboot from NCS 2.6.1 to NCS 2.9.0, the upgrade file is downloaded, and the device restarts and runs normally. The mcuboot version number and active slot are updated as expected. However, when the device is powered off and then powered on again, it fails to work properly, almost as if it has crashed. 

  • 0 in reply to Harvey Zheng

    Hi Harvey,

    Is the screenshot with logging from a failure case?

    From the screenshot in your first reply, it looks like you are running without MCUboot logging at all. There seem to be only logs from the application and NSIB. There might be clue in MCUboot logging. Could you please enable log level debug for MCUboot?

    You will need these configurations:

    CONFIG_LOG=y
    CONFIG_LOG_MODE_DEFERRED=y
    CONFIG_LOG_DEFAULT_LEVEL=4
    CONFIG_MULTITHREADING=y
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

    Another thing I want to consider is looking at hex dumps. It might be of interest to dump the entire memory at these points and track the changes:

    • Before new MCUboot download
    • After new MCUboot download, before first reset
    • Right after first reset
    • Right after second reset

    Hieu

  • 0 in reply to Hieu

    Hi,

    Hieu said:
    Is the screenshot with logging from a failure case?

    Yes, all failed log messages are from two attachments tested on nRF9160DK: ncs2.6.1.zip and ncs2.9.0.zip

    Hieu said:
    CONFIG_LOG=y
    CONFIG_LOG_MODE_DEFERRED=y
    CONFIG_LOG_DEFAULT_LEVEL=4
    CONFIG_MULTITHREADING=y
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

    I will try it for more helpful logging, thank you!

  • 0 in reply to Harvey Zheng
    Harvey Zheng said:
    CONFIG_LOG=y
    CONFIG_LOG_MODE_DEFERRED=y
    CONFIG_LOG_DEFAULT_LEVEL=4
    CONFIG_MULTITHREADING=y
    CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

    I will try it for more helpful logging, thank you!

    I forgot to mention. These should be configured in the MCUboot image only.

  • 0 in reply to Hieu

    Hi,

    Hieu said:
    I forgot to mention. These should be configured in the MCUboot image only.

    Since enabling DEBUG Logging in NCS2.6.1 MCUBoot would take up a lot of space, after trying it out I have not enabled it in the NCS2.6.1 example for now, and I will try to change the partition size if necessary.

    I had an important discovery in today's test, and synchronize it here

    I set the following KCONFIG in the NCS2.6.1 B0 configuration to y and it then successfully upgraded NCS2.6.1 MCUBoot to NCS2.9.0 MCUBoot. 

    CONFIG_BL_ROT_VERIFY_EXT_API_ENABLED=y
CONFIG_BL_SHA256_EXT_API_ENABLED=y
CONFIG_BL_SECP256R1_EXT_API_ENABLED=y
CONFIG_BL_VALIDATE_FW_EXT_API_ENABLED=y
CONFIG_EXT_API_PROVIDE_EXT_API_ENABLED=y

    The screenshot is the successful upgrade logging after I modified NCS2.6.1 B0.

    There are two questions about this:
    1. will these KCONFIG options have any effect on the upgrade? I'm guessing it will have an effect on mcuboot firmware validation?
    2. In the products we have produced, these KCONFIG options are disabled and B0 cannot be upgraded. I've tried setting the above options to n in NCS2.9.0 B0 to ensure consistency with the NCS2.6.1 example, but this causes it to stay at B0 after powering up, and not be able to jump to MCUBoot, which looks like the same phenomenon as the NCS2.6.1 MCUBoot upgrade to NCS2.9.0 failing. So how can I upgrade MCBoot to NCS2.9.0 without updating NCS2.6.1 B0?

  • 0 in reply to Harvey Zheng

    A bit of additional information:
    I compared the .config files generated by NCS2.6.1 MCUBoot and NCS2.9.0 MCUBoot. They seem to use different crypto, this is because bootloader\mcuboot\boot\zephyr\external_crypto.conf was merged when compiling NCS2.9.0, which wasn't there when NCS2.6.1 was build!

    Will this affect B0's validation of MCUBoot?

Reply Children
No Data
Related
Terms of service