NCS 3.4.0, compiling with ns option

Question

Good morning everyone. 
 I’m having some issues compiling my firmware using NCS 3.4.0 and the ‘ns’ option. I’m using an nRF9151DK board. Basically, my firmware compiles and flashes successfully, but it doesn’t run on the board. 
 As I couldn’t sort it out, I then carried out another test. I closed the entire workspace and started from scratch. I opened only the ‘blinky’ project. I built it using NCS 3.4.0 with the ‘ns’ option. I flashed it. No apparent issue until I switch the board on: the LED doesn’t light up and the serial port isn’t sending anything. 
 I then added a build configuration using NCS 3.3.0 and again the ‘ns’ option, flashed it, and it worked correctly. 
 I added another build configuration using NCS 3.4.0 but without the ‘ns’ option, flashed it, and again it worked. 
 At that point, I added a new build configuration again using NCS 3.4.0 and the ‘ns’ option: the result was the same as the first time. 
 Apart from the NCS version and the ‘ns’ option, all the other build settings were the same. I always did a pristine build. Without building again, I can flash on my board all the built versions and I get the same results. 
 I double-checked the installation of NCS 3.4.0 and tried reinstalling it, but the result is still the same. 
 I therefore believe that my development environment is not configured properly for this. 
 Could you please help me sort this out? 
 
 Thanks in advance. 
 Stefano

Simon D-M · Accepted Answer

Hi,

From my understanding, this is caused by the migration from "partition manager" to devicetree partitions that came with v3.4.0. In NCS, by default, MCUboot is disabled but currently the "MCUboot partition" is still in the default partition of the /ns chips. So, currently, if you want to build for a /ns chip, you have 2 solutions:

enable MCUboot by adding "SB_CONFIG_BOOTLOADER_MCUBOOT=y" to your sysbuild.conf

remove the MCUboot partition manually using an overlay file. Here is an example overlay file for the nRF9151 DK that I generated using AI:

/*
 * Remove MCUboot on nRF9151: TF-M secure image now starts at 0x0.
 * The secondary slot (slot1) is dropped since there is no bootloader/DFU.
 * SRAM (&sram0) is intentionally NOT modified — its split is defined by
 * the TrustZone secure/non-secure boundary and the modem shared memory,
 * neither of which depend on MCUboot.
 */

/delete-node/ &boot_partition;
/delete-node/ &slot0_partition;   /* also deletes slot0_s / slot0_ns children */
/delete-node/ &slot1_partition;   /* also deletes slot1_s / slot1_ns children */

&flash0 {
	partitions {
		/* Primary (and only) image area, now based at 0x0 */
		slot0_partition: partition@0 {
			compatible = "zephyr,mapped-partition";
			label = "image-0";
			reg = <0x00000000 0x70000>;      /* 448 KB */
			ranges = <0x0 0x0 0x70000>;
			#address-cells = <1>;
			#size-cells = <1>;

			slot0_s_partition: partition@0 {
				compatible = "zephyr,mapped-partition";
				label = "image-0-secure";
				reg = <0x00000000 0x40000>;   /* 256 KB TF-M secure */
			};

			slot0_ns_partition: partition@40000 {
				compatible = "zephyr,mapped-partition";
				label = "image-0-nonsecure";
				reg = <0x00040000 0x30000>;   /* 192 KB non-secure app */
			};
		};

		/*
		 * tfm_ps / tfm_its / tfm_otp / storage remain untouched
		 * at 0xf0000..0x100000 (defined in the base partition.dtsi).
		 */
	};
};

The nRF Connect SDK team is working on it. And, I believe it will be fixed soon in a next NCS revision.

Best regards,

Simon

NCS 3.4.0, compiling with ns option

Top Replies