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!

[Einar Thorsrud]

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?

[Yashaswini S]

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.

[Yashaswini S]

Hi,

I checked by making shorten the path still the error is same.

I have shared file down below. error message.

NOTE: after enabling the 

CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf file that time facing this error otherwise it builds with no erros.

Could please provide any suggestions to address this issue,

Thank you.

[Einar Thorsrud]

Hi,

Thank you. Here we see the error: "No fprotect backend selected.". The booltoader needs a mecahnism to lock the flash from being written to by the application, and different SoC's have different mechanisms for it, and if none of the mechanisms are enabled, you will get this printed here. This normally comes from the DeviceTree and is handled at the SoC level, so it should just work. I have seen one other instance though, which is discussed here, where the custom board was erronously based on the wrong starting point, mixing secure and non-secure, so that the nrf-spu was not present in the device tree (there will be other issues as well). Is that the case here as well?

[Yashaswini S]

Thank you for your input. It seems that the issue might be related to the DeviceTree configuration, particularly with the nrf-spu settings. Could you please provide if the nrf-spu is correctly defined and configured in the DeviceTree? How do we know that.

Thank you

[Einar Thorsrud]

Hi,

I do not see your device tree or board files, but the recomendation here is to copy the DK files and modify what you need. Remember to copy the _ns files if you are making an _ns board, and the secure (non _ns) files if that is appropriate.

[Yashaswini S]

Hi,

Even after modifying the dts file from the nrf5340dk into customized agora_bt40 dts, continue to encounter the same error.

After enabling the mcuboot on prj.conf it through error, otherwise builds without error.

[Einar Thorsrud]

Hi,

The error point to missing SPU configuration in the board as disussed before, so it seems MCU boot is built for non-secure or that the secure board configuration is incorrect, and does not contain the SPU (which it must). The nRF5340 is quite complex, so to avoid this the simplest is to copy all of the nRF5340 board files, and modify as needed for your custom HW. Note that you need both secure and non-secure board files as MCUboot will always be built as secure even if the application is non-secure.

If you have not made any progress, can you share your board files as well as full build log (so that I see how you build the project as well as any errors)?

[Yashaswini S]

Hi, 

While working on DTS file, in C:\ncs\v2.7.0\zephyr\boards\nordic\nrf5340dk I have seen different dts file so here which one has to select to work with bootloader development.

nrf5340_cpuapp_common.dtsi, nrf5340_cpuapp_partition_conf.dtsi,nrf5340dk_nrf5340_cpuapp.dts,nrf5340dk_nrf5340_cpuapp_ns.dts so I have seen these 4 dts files.

While in our customized agora board we having nrf5340dk, when i try to compare with dts file which file should I need to consider, in that 4.

Thank you

[Einar Thorsrud]

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.

[Yashaswini S]

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

[Einar Thorsrud]

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