• State Not Answered
  • Replies 19 replies
  • Subscribers 69 subscribers
  • Views 498 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 336251
Options

Issue with Enabling MCUboot on Custom Board with nRF5340

Yashaswini S

Hello,

I am working on a custom Agora board that includes a BT40 module with an nRF5340 MCU. I am trying to enable the MCUboot bootloader by setting CONFIG_BOOTLOADER_MCUBOOT=y in my prj.conf file. However, I encounter an error during the initial configuration stage.

Here are the details of my setup:

  • Custom Agora board with BT40 module
  • nRF5340 MCU
  • Using Nordic SDK version 2.7.0
  • The bootloader demo works on the nRF52840 development board using the Nordic course

Error Message:

...depends again on SOC_FAMILY_NRF (defined at C:/ncs/v2.7.0/modules/soc-hwmv1/soc/arm\nordic_nrf\Kconfig:9)
CMake Error at C:/ncs/v2.7.0/zephyr/cmake/modules/kconfig.cmake:392 (message):
command failed with return code: 1
Call Stack (most recent call first):
C:/ncs/v2.7.0/nrf/cmake/modules/kconfig.cmake:29 (include)
C:/ncs/v2.7.0/zephyr/cmake/modules/zephyr_default.cmake:132 (include)
C:/ncs/v2.7.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
C:/ncs/v2.7.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:97 (include_boilerplate)
CMakeLists.txt:12 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/Users/YASHAWS/Agora/xyleminc-wwno-gnode-009afda753b5/build_4/mcuboot/CMakeFiles/CMakeOutput.log".
See also "C:/Users/YASHAWS/Agora/xyleminc-wwno-gnode-009afda753b5/build_4/mcuboot/CMakeFiles/CMakeError.log".
CMake Error at C:/ncs/v2.7.0/nrf/cmake/multi_image.cmake:502 (message):
CMake generation for mcuboot failed, aborting. Command: 1
Call Stack (most recent call first):
C:/ncs/v2.7.0/nrf/cmake/multi_image.cmake:178 (add_child_image_from_source)
C:/ncs/v2.7.0/nrf/modules/mcuboot/CMakeLists.txt:328 (add_child_image)


-- Configuring incomplete, errors occurred!
See also "C:/Users/YASHAWS/Agora/xyleminc-wwno-gnode-009afda753b5/build_4/CMakeFiles/CMakeOutput.log".
See also "C:/Users/YASHAWS/Agora/xyleminc-wwno-gnode-009afda753b5/build_4/CMakeFiles/CMakeError.log".
FAILED: build.ninja
C:\ncs\toolchains\ce3b5ff664\opt\bin\cmake.exe --regenerate-during-build -SC:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5 -BC:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5\build_4
ninja: error: rebuilding 'build.ninja': subcommand failed
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\ce3b5ff664\opt\bin\cmake.EXE' --build 'c:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5\build_4'

* The terminal process terminated with exit code: 1.
* Terminal will be reused by tasks, press any key to close it.

Could anyone provide guidance on how to resolve this issue or suggest additional configurations that might be required for the nRF5340 MCU on a custom board?

Thank you!

Parents
  • 0

    Hi,

    I amo not able to see exactly what the error is, but it the path is long which can cause problems on windows. I sit possible to rename and move things so that you make "C:/Users/YASHAWS/Agora/xyleminc-wwno-gnode-009afda753b5" much shorter? Do you still see the same error after that?

  • 0 in reply to Einar Thorsrud

    Hi,

    Thank for the suggestion. I'll try to shorten the path.

    But the Error is -FAILED: build.ninja
    C:\ncs\toolchains\ce3b5ff664\opt\bin\cmake.exe --regenerate-during-build -SC:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5 -BC:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5\build_4
    ninja: error: rebuilding 'build.ninja': subcommand failed
    FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\ce3b5ff664\opt\bin\cmake.EXE' --build 'c:\Users\YASHAWS\Agora\xyleminc-wwno-gnode-009afda753b5\build_4'

    This is the main issue is facing and after enabling the CONFIG_BOOTLOADER_MCUBOOT=y on prj.conf file.

  • 0 in reply to Yashaswini S

    Hi,

    There are 3 main boards for the nRF5340 DK in the SDK:

    • nrf5340dk_nrf5340_cpuapp
    • nrf5340dk_nrf5340_cpuapp_ns
    • nrf5340dk_nrf5340_cpunet

    All these boards consist of several files each. If you are using the net core as well as the app core (which you always need for using the radio), you need nrf5340dk_nrf5340_cpunet in addition to nrf5340dk_nrf5340_cpuapp. And if you are using TrustZone, you need nrf5340dk_nrf5340_cpuapp_ns for the non-secure application. However, you also need nrf5340dk_nrf5340_cpuapp for the secure builds, which is for instance the bootloader. The bootloader is always a secure build. And the error you are getting indicate that you are attempting to build the bootlodaser for a non-secure board, which will not work.

    For the files you list:

    • nrf5340_cpuapp_common.dtsi file is included in both the nrf5340dk_nrf5340_cpuapp and nrf5340dk_nrf5340_cpuapp_ns boards.
    • nrf5340_cpuapp_partition_conf.dtsi is also includedin both, by being included in nrf5340_cpuapp_common.dtsi.
    • nrf5340dk_nrf5340_cpuapp.dts is the device tree file for the secure board. This is used for all secure builds (bootloaders etc), but not non-secure applications.
    • nrf5340dk_nrf5340_cpuapp_ns.dts is used if you have a non-secure application (i.e. you are including TF-M to utilize TrustZone).

    In short, as you are using a non-secure application, you need both secure and non-secure boards. And as this is quite complex to get right, I recomend you take all of the nRF5340 DK files and copy and rename to use as your custom baord files. You can see more practical information on this under Board files for multi-core hardware & TF-M in the intermediate nRF Connect SDK course.

  • 0 in reply to Einar Thorsrud

    Hi,

    I have followed the steps as you mentioned, copied all the dk files and renamed to custom board name. That is working fine now. able to build successfully without error and also try to update the firmware using mcumgr commands.

    But now i have another issue, 

    1.here the once after giving uart configurations that has to show two image slots information that is not getting here.

     

    2.once after giving new firmware using upload command it is taking after that it is showing complete two slots details.

    3. After updating the secondary memory details to primary using HASH value return with done.

    4. since after that need to reset the microcontroller then the new firmware will load into primary address i.e image 0 where the main application is running. but here after the reset it is not updating with new firmware, once after giving to check image list i am able to see only the slot 0 details with previous HASH value not with new firmware updated value.

    Could you help me to address this, what is the reason for this?

    Thank you

  • 0 in reply to Yashaswini S

    Hi,

    I am glad to see you were able to get the board files right.

    Regarding the DFU issue, I see uploading the image works well, but soemthing goes wrong during activation/swapping and the new image is never booted. There could be serveral reasons for that, though. Is the version of the new image not higher? Or is it signed with an invalid key? One way to see this better is to enable logging in the bootlodaer and see what it does (and why).

  • 0 in reply to Einar Thorsrud

    Hi,

    I tried by creating byown private and public key and adding with to existing project.

    Do you any reference for the adding the keys to existing project.since after adding the keys also not reflcting in the project.

    and also issue still persists.

    Thank you

  • 0 in reply to Yashaswini S

    Hi,

    Adding keys are described under Enabling a bootloader chain using sysbuild. For older SDK versions or if you are using the parent-child image, you need to follow the instructions under Enabling a bootloader chain using child and parent images (deprecated).

    If you face issues, can you elaborate on what you are doing an in what way it does not work?

Reply Children
Related