Issue with Enabling MCUboot on Custom Board with nRF5340

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

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

  • Hi, 

    above Image that you shared also the one of the issues I'm getting, rather than that I have major one, for that issue itself I raised the ticket.

    In the down I mentioned can you that and help us to resolve that,

    1. The difference between the dk and custom board will be on dts file and peripherals.

    2. I am using mcumgr command line tool to perform DFU. I have used same commands mentioned in Exercise 1 - DFU over UART - Nordic Developer Academy By using this i am able do the DFU for nRF5340dk board and new firmware upgrade sucessfully.

    I will share the commands which used to update new firmware using mcumgr commands.

    At this time new firmware binary file upload but after the reset that new is not reflecting the hardware.

    You can see the pending permanent after trying swap to primary address.

    after that I will do reset then also the same.

    The same bootloader that works successfully on DK board, when I tried same thing with the custom board, new firmware is not updating in the hardware, but commands are working.

    Thank you

         

  • Hi,

    Yashaswini S said:
    above Image that you shared also the one of the issues I'm getting, rather than that I have major one, for that issue itself I raised the ticket.

    Yes, I thought that was for the DK? If not, it is odd that mcumgr communication worked first, and then suddently did not.

    Yashaswini S said:
    The same bootloader that works successfully on DK board, when I tried same thing with the custom board, new firmware is not updating in the hardware, but commands are working.

    OK, everything looks good here, with nothing here explaining why the new image is not activated. Do you have logging enabled in MCUboot? If not, can you enable it and share the log here? That should show us what happens after the reste when the new image should have been swapped in and booted.

  • Hi

    Logging enabled in mcuboot: can you give, how can I do this to enable see the logs.

    Thank you

  • In most cases it should be enough to ensure you have the following in the mcuboot configuration:

    CONFIG_LOG=y
    CONFIG_MCUBOOT_LOG_LEVEL_INF=y

  • Hi, 

    After updating the above commands on mcuboot.conf in the RTT log I'm getting these debug messages.

    Thank you

Reply Children
  • Hi

    when I checked in debug mode I got below response, after uploading to new image.

    By the time it enters to line no 327 board will start reset.

    I am not able to understand the behavior, why it is resting.

    Thank you

  • Hi,

    The error in the previous post indicate attemting to communicate with an external flash device (the one that is on the DK), but that does not work. So it seems like your board files stil refer to the external flash from the DK even though that is not present on your custom board? If so, that should be removed. It could be that just adding this in an .overlay to start with would be enough:

    /delete-node/ &mx25r64;
    
    &qspi {
    	status = "disabled";
    };

    (but this needs to be disabled both in the app and the bootloader, so fixing the board files is best and cleanest)

Related