nRF9160 firmware upgrade process no longer works

[Taylor]

I implemented firmware update over LTE Cat-M and Ethernet last year by modifying the `fota_download` and the `download_client` examples into my own slightly modified version, which has functions that choose ethernet or LTE depending on what's available for the download.

While preparing the firmware release for the production units I decided to test the firmware update and found it no longer works.

I've implemented the code using the nRF Connect SDK v2.2.2, which initially worked last year when tested.

So far, from my testing, I can tell it is correctly downloading the firmware image from the client's server. However, it doesn't seem to apply the firmware update after downloading it, even when using `dfu_target_schedule_update(0)` or `boot_request_upgrade(BOOT_UPGRADE_PERMANENT)`. From additional debug information, I can tell that it is writing the MCU image type as 0x03, which should be permanent.

Development software: JLinkRTT Viewer, nRF Connect SDK v2.2.2

Computer platform: Ubuntu 24.04

Note that I am using the MCU boot key, which is publically known at the moment, not a custom key for signing.

Attached is a version of the firmware with most things removed except for the modem and firmware update code.

0564.controller-ng.tgz

[Taylor]

After doing a lot of debugging I found the issue is due to my overlay file not being picked up by the build system

I have the overlay located in `child_image/mcuboot/boards/nrf9160dk_nrf9160_ns.overlay` and `child_image/mcuboot/boards/nrf9160dk_nrf9160.overlay`. The file contains the following.

&uart1 {
	status = "disabled";
};

&i2c2 {
	status = "disabled";
};

&uart0 {
	status = "disabled";
};

&pwm_led0 {
	status = "disabled";
};


&led0 {
	status = "disabled";
};


&led1 {
	status = "disabled";
};

&led2 {
	status = "disabled";
};

&led3 {
	status = "disabled";
};


&button0 {
	status = "disabled";
};

&button1 {
	status = "disabled";
};

&button2 {
	status = "disabled";
};

&button3 {
	status = "disabled";
};

&spi3 {
	cs-gpios = <&arduino_header 16 GPIO_ACTIVE_LOW>, /* D10 */
		   <&gpio0 25 GPIO_ACTIVE_LOW>;
	mx25r64: mx25r6435f@1 {
		compatible = "jedec,spi-nor";
		reg = <1>;
		spi-max-frequency = <8000000>;
		jedec-id = [c2 28 17];
		sfdp-bfp = [
			e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
			ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
			10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
			30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
		];
		size = <67108864>;
		mxicy,mx25r-power-mode = "high-performance";
	};
};

/* Enable high drive mode for the SPI3 pins to get a square signal at 8 MHz */
&spi3_default {
	group1 {
		nordic,drive-mode = <NRF_DRIVE_H0H1>;
	};
};

/ {
	aliases {
		ext-flash = &mx25r64;
	};

	/* Configure partition manager to use mx25r64 as the external flash */
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

On the initial build the overlay file is picked up, however, if I build it again then the file is excluded and it results in the firmware update not working due to the external flash not being part of the device tree.

Any solution to get this to always be included for the mcuboot image?

[Achim Kraus]

Rather a work-around: always use "--pristine".

[Taylor]

It seems that doing that doesn't really resolve the issue. What I ended up doing was deleting the build directory from VS Code and then recreating the build for the target board.

If the build fails, running the pristine a few times will get it to build correctly.