• State Verified Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 76 subscribers
  • Views 1161 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 304563
Options

nrf connect sdk: MCUBOOT build error

amiramin

Hi,

So far, we have been using NRF5 SDK for our BLE product using nrf52840. For the next gen product, we would like switch to Nrf Connect SDK. I installed NCS 2.3.0 and tries few BLE demos which seems to work fine. 

We want to enable the OTA update over BLE as first step in our product with possibility to update from nrf connect app:

- MCUBoot is the right option for this? or we better look into Nordic Immutable secure bootloader?

- As first test, i started the MCUBoot tutorial (SMP server sample) from following link

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#smp-svr-sample

The SMP server samples builds fine:

amir@CPU047 MINGW64 /c/ncs/v2.3.0/zephyr ((v3.2.99-ncs2))
$ west build --pristine -b nrf52840dk_nrf52840 samples/subsys/mgmt/mcumgr/smp_svr/ -- -DOVERLAY_CONFIG=overlay-bt.conf
.
.
sign the payload
[311/311] Generating zephyr/merged.hex

However, building for MCUBOOT fails:

amir@CPU047 MINGW64 /c/ncs/v2.3.0
$ west build --pristine -b nrf52840dk_nrf52840 -d build_mcuboot bootloader/mcuboot/boot/zephyr/
-- Zephyr version: 3.2.99 (C:/ncs/v2.3.0/zephyr), build: v3.2.99-ncs2
[124/189] Building C object CMakeFiles/app.dir/nrf_cleanup.c.obj
FAILED: CMakeFiles/app.dir/nrf_cleanup.c.obj
C:\ncs\toolchains\v2.3.0\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DKERNEL -DMBEDTLS_CONFIG_FILE=\"C:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr/include/mcuboot-mbedtls-cfg.h\" -DNRF52840_XXAA -DUSE_PARTITION_MANAGER=0 -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr/include -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr/targets -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/bootutil/include -IC:/ncs/v2.3.0/bootloader/mcuboot/ext/mbedtls-asn1/include -IC:/ncs/v2.3.0/bootloader/mcuboot/ext/nrf -IC:/ncs/v2.3.0/zephyr/include -Izephyr/include/generated -IC:/ncs/v2.3.0/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/ncs/v2.3.0/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.3.0/nrf/include -IC:/ncs/v2.3.0/nrf/tests/include -IC:/ncs/v2.3.0/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.3.0/modules/hal/nordic/nrfx -IC:/ncs/v2.3.0/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.3.0/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.3.0/zephyr/modules/hal_nordic/nrfx/. -IC:/ncs/v2.3.0/modules/debug/segger/SEGGER -IC:/ncs/v2.3.0/modules/debug/segger/Config -IC:/ncs/v2.3.0/zephyr/modules/segger/. -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/.. -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/../include -IC:/ncs/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/../../zephyr/include -IC:/ncs/v2.3.0/nrfxlib/crypto/nrf_cc310_bl/include -isystem C:/ncs/v2.3.0/zephyr/lib/libc/minimal/include -isystem c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include -isystem c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include-fixed -isystem C:/ncs/v2.3.0/nrfxlib/crypto/nrf_cc310_platform/include -fno-strict-aliasing -Os -imacros C:/ncs/v2.3.0/build_mcuboot/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mfp16-format=ieee --sysroot=C:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.3.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.3.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.3.0=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/nrf_cleanup.c.obj -MF CMakeFiles\app.dir\nrf_cleanup.c.obj.d -o CMakeFiles/app.dir/nrf_cleanup.c.obj -c C:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr/nrf_cleanup.c
C:/ncs/v2.3.0/bootloader/mcuboot/boot/zephyr/nrf_cleanup.c:24:10: fatal error: pm_config.h: No such file or directory
   24 | #include <pm_config.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
[137/189] Building C object CMakeFiles/app.dir/C_/ncs/v2.3.0/bootloader/mcuboot/boot/bootutil/src/loader.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\v2.3.0\opt\bin\cmake.EXE' --build 'C:\ncs\v2.3.0\build_mcuboot'

The pm_config.h file is indeed present in C:\ncs\v2.3.0\zephyr\build\mcuboot\zephyr\include\generated folder and build does not find it (neither the 'generated' folder is part of include path directly)

What could be going wrong here?

Thanks for looking into it.

Regards,

Amir

  • 0

    Hi Amir,

    I've gotten MCUboot working in the past for one of our products and was similarly confused by the same thing that you are. The documentation for that sample makes it sound like you have to build mcuboot and the app in separate steps, but I don't think that's the case. I can confirm that the smp_svr app works without you building MCUboot separately by hand. All you need to do is build the app like normal in VScode and it knows to build MCUboot for you based on the presence of your child_image folder and the "CONFIG_BOOTLOADER_MCUBOOT=y" option.

    You can see it building MCUboot when you build the smp_svr app, it's called the "child_image". When you build you should see:

    MCUBoot bootloader key file: C:/ncs/v2.3.0/bootloader/mcuboot/root-ec-p256.pem
-- Configuring done
-- Generating done
-- Build files have been written to: C:/OPTIX_PRODUCTION/smp_svr_2.3.0/build/mcuboot
=== child image mcuboot -  end ===

    You can see where it's building MCUboot separately and placing it into its own build folder.

    My reasoning may be flawed, and I'm looking forward to how someone from Nordic would answer this, but I can at least confirm that the smp_svr app works fully without having to explicitly build MCUboot separately from the main app (it automatically does it for you).

  • 0

    Hi,

    Thanks  for the hint. I can confirm that it is not required to separately build the MCUBOOT. I flashed the merged.hex file and our board starts to advertise. And I also managed to test the OTA update using the nrf connect app.

    Cheers

    Amir

  • +1

    Hello,

    Glad to hear that you resolved your issue. Adding something just for clarity: When you include the configuration ⁠CONFIG_BOOTLOADER_MCUBOOT to your project (in prj.conf), this will include MCUBOOT as the bootloader and you see this as a separate project mentioned as child image inside the Application.

    You can also check the Adding DFU support guide from nordic.

    Kind Regards,

    Abhijith

Related
Terms of service