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.

[Einar Thorsrud]

Hi,

I am sorry for the delay. As you get a timeout it seems that there is no communication, as mentionned earlier. Which UART pins are you using on the custom board, and how have you configured your devicetree accordingly? And have you connected the correct pins to your USB-UART interface?

[Yashaswini S]

Hi,

I have crosschecked the pin details on devicetree and everything is mapped according to the datasheet.

I am having another issue, that I mentioned earlier like dual swap method is not reflecting in the hardware, which I shared the commands also in previous discussion. we have tried

1. We already tried taking the NRF5340DK_nrf5340 folder and copying it to an Agora_bt40 folder, then replaced all references to nrf5340dk_nrf5340 with Agora_bt40. 
2. We took the elements of the agora_bt40.dts file which are different from the standard nRf5340DK and reflected those changes in the agora_bt40_common.dtsi file. But the response is same.
3. Also, the slot partitions changed in agora_bt40_common.dtsi wrt agora_bt40.dts.
4. We made the agora_bt40.dts to agora_bt40.overlay and tried. 

Still the LED blink bin file loading through bootloader doesn’t reflect in the hardware.

These are thing which we tried but the successfully new bin file is loading but once i press the reset after that, changes are not reflecting in the hardware.

But in the dk board it works successfully, with the custom board the issue is happening.

Thank you

[Einar Thorsrud]

Hi,

Yashaswini S said:

I have crosschecked the pin details on devicetree and everything is mapped according to the datasheet.

Do you get UART working for other use cases, such as logging? With the same instance? If not, it could be good to verify that the UART pins used in the genrated zephyr.dts in the build folder points to the actual UART pins on your hardware.

Yashaswini S said:

I am having another issue, that I mentioned earlier like dual swap method is not reflecting in the hardware, which I shared the commands also in previous discussion. we have tried

I am a bit confused about this, as from what I am able to see you are not able to communicate at all with the custom board over UART with mcumgr. So is this with a DK, or did I misunderstand?

Yashaswini S said:

These are thing which we tried but the successfully new bin file is loading but once i press the reset after that, changes are not reflecting in the hardw

After the firmware is transvered it needs to be activated. This can be done permanently or a single time ("test"). This must be configured before the reset, and then the bootloader will swap in the new image upon boot. If there are issues here, perhaps you can share exactly what you are doing (specifying board and step by step instrutions), and in what way it does not work?

[Yashaswini S]

Hi

1. I am a bit confused about this, as from what I am able to see you are not able to communicate at all with the custom board over UART with mcumgr. So is this with a DK, or did I misunderstand?

No, with the DK able to communicate and bootloader loads the new firmware using mcumgr commands, but with the custom board which is having the mrf5340mcu with BT40 module to this module not able to upload the new firmware.

But the commands are working fine, if i give upload the new binary file it loads but after the reset it is not reflecting in hardware. 

2. After the firmware is transvered it needs to be activated. This can be done permanently or a single time ("test"). This must be configured before the reset, and then the bootloader will swap in the new image upon boot. If there are issues here, perhaps you can share exactly what you are doing (specifying board and step by step instrutions), and in what way it does not work?

After the updating I'm giving the confirm to done permanently swap with primary address.This one also I'm doing before the reset it itself by giving mcumgr -c testDK image confirm <NEW_HASH>. 

Thank you

[Einar Thorsrud]

Hi,

I see. Can you show the terminal output from all mcumgr command you use when you upload the image to the custom board? If I understand correctly, the only log I have seen from that is this, which does not show any successfull communication:

If you are able to upload the firmware via SMP but not activate it, that is odd, but seeing the whole set of commands (including the listed images before you attempt to test or confirm) could be usefull. Plese show the shole sequence of commands and responses by copy-pasting from the terminal.

[Yashaswini S]

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

     

[Einar Thorsrud]

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.