Trying to perform OTA to a nRF52840 device via nRF9160 LTE connection

[Giannis Anastasopoulos]

Dear All,

What I need is to be able to perform a DFU on a nRF52840 device that has a UART connection to nRF9160 device that can download the bin file for the nRF52840 device.

I have seen that there are 3 main threads on the topic:

https://devzone.nordicsemi.com/f/nordic-q-a/90110/send-dfu-image-between-two-nrf5340
https://devzone.nordicsemi.com/f/nordic-q-a/79779/firmware-update-ota-of-nrf9160-by-ble-nrf52840-and-update-nrf52840-by-fota-of-nrf9160/330275

 RE: Perform NRF52840 OTA over the NRF9160 and UART

From what I gather from the posts above, there was a pull-request at some point that is now closed that was doing exactly what I am looking for.
I have tried to implement the changes described on this pull request and tried to compile initially a very basic project for the nRF52840.

At the very start of the build process, I am getting this error:

 Found assembler: C:/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
usage: zcbor.py [-h] [--version] -c CDDL [--default-max-qty DEFAULT_MAX_QTY]
                [--no-prelude] [-v]
                {code,convert} ...
zcbor.py: error: the following arguments are required: -c/--cddl
CMake Error at C:/ncs/nrf/subsys/dfu/dfu_target/src/dfu_target_uart_cddl/CMakeLists.txt:19 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 2"



-- Configuring incomplete, errors occurred!
←[91mFATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=C:\Python311\python.exe' '-BC:\Users\Desktop\nRF52\build' -GNinja -DBOARD=nrf52840dk_nrf52840 -DSIGNED=Signed '-SC:\Users\Desktop\nRF52'
←[0m

Any ideas what do I need to do in order to fix this and move on with allowing the application to compile?

I am using NCS v2.1.0 running on Windows

[Sigurd Hellesvik]

Hi,

First, I just want to check:

Do you run separate applications for both the nRF52840 and the nRF9160?
The alternatives would be something like Serial LTE Modem or HCI Uart.

Regards,
Sigurd Hellesvik

[Giannis Anastasopoulos]

Not sure what you mean. What I am initially trying to achieve is to download a FOTA file, via LTE on the nRF9160 and then set the nRF52840 in DFU mode and send it the new image via UART and then have it running the new image.

From what I understand the PR above downloads the bin file in segments and sends each segment directly via UART to the nRF52840, which is also acceptable.

Currently, I am stuck with building the nRF52840 application that does what is shown in the sample for the nRF53 (although there is nothing special to the nRF53, from what I can understand in the prj.conf).

The only thing that I am also not sure of is

CONFIG_UPDATEABLE_IMAGE_NUMBER=2

Is this needed for the nRF52840?

[Sigurd Hellesvik]

Giannis Anastasopoulos said:

Is this needed for the nRF52840?

It is not.

Let's take a birds eyes view over what you are trying to do:

You want to perform DFU between two DKs.
This is done using firmware called mcumgr.
mcumgr use the SMP Protocol for updates. In this case, a SMP Client sends the update to a SMP Server.

We have a working SMP Server, and this comes in two types, either SMP Server in the application or Serial Recovery. I explain both these in my unofficial bootloader samples.
If you want to update the nRF52840, you will need a SMP Server on the nRF52840. Serial Recovery uses less memory and is more robust, so I would recommend that for this purpose.

Then on your nRF9160, you will need an SMP Client.
As you say, we are working on an SMP Client in the nRF Connect SDK. This has not been released yet, but will be part of an nRF Connect SDK tag in the future. (Ask sales for timeline)
In the meantime, you have some alternatives:

• Use the Pull requests implementing this into your nRF Connect SDK
  • This will be easier if you use the newest version of the nRF Connect SDK.
    The mcumgr code has changed paths since v2.1.0, so implementing the changes will require you to patch most of the mcumgr drivers.
  • Here is an Pull request for our official implementation. https://github.com/zephyrproject-rtos/zephyr/pull/56934
• Alternatively, you can use an unofficial sample which implements an SMP Client as a sample, without read driver support yet. I have an unofficial sample at my github repo.
  • This code/configuration is not thoroughly tested or qualified and should be considered provided “as-is”. Please test it with your application and let me know if you find any issues.

Here are a couple of cases where I have discussed similar stuff before:

 BLE FOTA example for Central device 

 Information on how to perform a FOTA update on nRF52811

From what I gather from the posts above, there was a pull-request at some point that is now closed that was doing exactly what I am looking for.

My options above explain how to do an SMP Client.
Still, some code is needed to first download the update from FOTA and then send it using the SMP Client.
This is what the PR you refer to has been trying to fix.
So it is up to you if you want to implement such a feature yourself, if you want to try to use the PR or if you want to wait for us to implement such functionality officially in the nRF Connect SDK. Ask sales if you want to know about timelines)

Any ideas what do I need to do in order to fix this and move on with allowing the application to compile?

Which command did you run when you got this error?

[Giannis Anastasopoulos]

 Sigurd Hellesvik 

I am trying to use your samples on my custom nRF52840 board.

For the most part I am successful so far with getting the device to DFU mode.

There is just one issue that I have encountered:

Since my board is a custom one, in order to get it to work, I am applying an overlay file.

From what I see when the project compiles, the overlay is picked and applied on the board of the main application, but this is not the case for the MCUboot build:

For the normal application:

-- Found BOARD.dts: C:/ncs/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Found devicetree overlay: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/nrf52840dk_nrf52840.overlay
-- Generated zephyr.dts: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/zephyr/include/generated/devicetree_unfixed.h

For the MCUboot:

=== child image mcuboot -  begin ===
loading initial cache file C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/mcuboot/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base).
-- Application: C:/ncs/bootloader/mcuboot/boot/zephyr
-- Found Python3: C:/Python311/python.exe (found suitable exact version "3.11.4") found components: Interpreter 
-- Cache files will be written to: C:/ncs/zephyr/.cache
-- Zephyr version: 3.1.99 (C:/ncs/zephyr)
-- Found west (found suitable version "1.1.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Found host-tools: zephyr 0.15.2 (C:/Users/np080/zephyr-sdk-0.15.2)
-- Found dtc: C:/ProgramData/chocolatey/bin/dtc.exe (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: zephyr 0.15.2 (C:/Users/np080/zephyr-sdk-0.15.2)
-- Found BOARD.dts: C:/ncs/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Found devicetree overlay: C:/ncs/nrf/modules/mcuboot/usb.overlay
-- Found devicetree overlay: C:/ncs/bootloader/mcuboot/boot/zephyr/dts.overlay
-- Generated zephyr.dts: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/mcuboot/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/mcuboot/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/mcuboot/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/Users/np080/Desktop/GIT_Projects/mcuboot_serial_recovery_uart/build/mcuboot/zephyr/dts.cmake

As a result I cannot reset the device to DFU because the MCUboot uses a different pin.

My overlay file looks like this:

&uart0 {
	compatible = "nordic,nrf-uarte";
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart0_default>;
	pinctrl-1 = <&uart0_sleep>;
	pinctrl-names = "default", "sleep";
};

&uart1 {
	status = "disabled";
};

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 14)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 1, 15)>;
			bias-pull-up;
		};
	};

	uart0_sleep: uart0_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 14)>,
					<NRF_PSEL(UART_RX, 1, 15)>;
			low-power-enable;
		};
	};
};

/ {
	buttons {
		compatible = "gpio-keys";

		button0: button_0 {
			gpios = <&gpio0 6 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 0";
		};
	};
	leds {
		compatible = "gpio-leds";
		led0: led_0 {
			gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
			label = "Green LED 0";
		};
	};

	aliases {
		inputpin1 = &button0;
		customled0 = &led0;
		bootloader-led0 = &led0;
		mcuboot-button0 = &button0;
		mcuboot-led0 = &led0;
	};
};

&qspi {
	status = "disabled";
};

What I found out is that if I copy the nRF52840dk_nRF52840 into my project, manually change the dts and dtsi to match the stuff I have on my overlay and compile then the whole thing works.

So what I wonder is if there is anyway to apply my overlay to the MCUboot board as well without touching the SDK files.

[Sigurd Hellesvik]

Giannis Anastasopoulos said:

What I found out is that if I copy the nRF52840dk_nRF52840 into my project, manually change the dts and dtsi to match the stuff I have on my overlay and compile then the whole thing works.

So what I wonder is if there is anyway to apply my overlay to the MCUboot board as well without touching the SDK files.

Yes.

Indeed, you have found one of the important features of Zephyr: Board files.

We provide board files for our Developement kits, with names such as "nrf52840dk_nrf52840".
You can overlay these, meaning that you add extra configurations to them, but keep the rest.

However, if you design your own board, I recommend that you create custom board files to fit this board.
You can build your project with "-- -DBOARD_ROOT=<PATH_TO_BOARD_FILES>" to point the build to your custom board files, and thus add them without changing the SDK.

Here are some useful docs and tools:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/board_support.html#custom-boards

https://nrfconnect.github.io/vscode-nrf-connect/guides/bd_boards_devices.html?h=board

https://nrfconnect.github.io/vscode-nrf-connect/reference/ui_sidebar_welcome.html?h=new+board#create-a-new-board

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/hardware/porting/board_porting.html#board-porting-guide

Does this make sense?