Issue building NUS with UART on nRF5340 (APP_CORE)

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Fri, 27 Mar 2026 12:32:44 GMT

Hi Sigurd,

I couldn't solve the issue, but I was able to work around it.

For some reason, in my case, using instance 2—whether UART or SPI—caused the same problem during the build.
So I switched my SPI0 to SPI4 and used UART0 instead of UART2. After that, the build succeeded and the application is working well.

Thanks for your support!

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Sigurd Hellesvik — Wed, 25 Mar 2026 08:36:01 GMT

Hm, nothing obivous in the zephyr.dts.

You dont by chance have a bootloader in your project?

If not, are you able to upload a minimal sample where I can reproduce the error?

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Tue, 24 Mar 2026 19:32:52 GMT

Any update?

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Fri, 20 Mar 2026 14:51:28 GMT

Sure.

On build/<PROJECT>/zephyr:

devzone.nordicsemi.com/.../8420.zephyr.dts

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Sigurd Hellesvik — Fri, 20 Mar 2026 13:15:11 GMT

Good, this new error message is one step closer.

The IRQ number 11 is related to Peripheral instantiation. See that UART2 has number 11.

So it points to the same that Veal is suggesting as welll.

Could you also upload build/PROJECT/zephyr/zephyr.dts? Then I can check all peripherals that is enabled in the final compiled DTS configuration.

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Fri, 20 Mar 2026 13:07:47 GMT

"When I enable UART2, I encounter the following build error:"

The only change I made was uncommenting this section:

&uart2 {

status = "okay";

current-speed = <115200>;

pinctrl-0 = <&uart2_default>;

pinctrl-1 = <&uart2_sleep>;

pinctrl-names = "default", "sleep";

};

With this section commented out, I don't get any errors. When uncommented, I get the errors shown previously.

Regarding my logging configuration, I want to use RTT output. I'm currently using this in prj.conf:

# LOG and RTT

CONFIG_LOG=y

CONFIG_CONSOLE=y

CONFIG_RTT_CONSOLE=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_BACKEND_RTT=y

CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=1024

Following your suggestion, I added:

CONFIG_UART_CONSOLE=n

With this addition, I get a different error when uncommenting the UART2 lines. The error is:

[744/747] Generating isr_tables.c, isr_tables_vt.ld, isr_tables_swi.ld
FAILED: zephyr/isr_tables.c zephyr/isr_tables_vt.ld zephyr/isr_tables_swi.ld /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x/zephyr/isr_tables.c /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x/zephyr/isr_tables_vt.ld /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x/zephyr/isr_tables_swi.ld 
cd /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x/zephyr && /home/santos/ncs/toolchains/7cbc0036f4/usr/local/bin/python /home/santos/ncs/v3.0.2/zephyr/scripts/build/gen_isr_tables.py --output-source isr_tables.c --linker-output-files isr_tables_vt.ld isr_tables_swi.ld --kernel /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x/zephyr/zephyr_pre0.elf --intlist-section .intList --intlist-section intList --sw-isr-table --vector-table
gen_isr_tables.py: error: multiple registrations at table_index 11 for irq 11 (0xb)
Existing handler 0x4a675, new handler 0x49b09
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?
ninja: build stopped: subcommand failed.
[19/30] cd /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/_sysbuild && /home/santos/ncs/toolchains/7cbc0036f4/usr/local/bin/cmake -E true
FAILED: _sysbuild/sysbuild/images/life_finder_nrfconn_3x-prefix/src/life_finder_nrfconn_3x-stamp/life_finder_nrfconn_3x-build /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/_sysbuild/sysbuild/images/life_finder_nrfconn_3x-prefix/src/life_finder_nrfconn_3x-stamp/life_finder_nrfconn_3x-build 
cd /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build/life_finder_nrfconn_3x && /home/santos/ncs/toolchains/7cbc0036f4/usr/local/bin/cmake --build .
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /home/santos/ncs/toolchains/7cbc0036f4/usr/local/bin/cmake --build /home/santos/Documents/FirmwareLifeFinder/life_finder_nrfconn_3x/build

with devicetree_generated.h:

devzone.nordicsemi.com/.../7266.devicetree_5F00_generated.h

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Sigurd Hellesvik — Fri, 20 Mar 2026 12:41:13 GMT

Line 148 in this one points to uart0.

Looks like you enable logging in your application, which will default to uart0. But then you disable uart0 in DTS.

Do you want logging to be enabled?
If so, which UART do you want to log to?

When you said:

[quote user=""]When I enable UART2, I encounter the following build error:[/quote]

Exactly which changes did you make?

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Fri, 20 Mar 2026 12:30:17 GMT

Ah yes, now I understand. Next, with enable &uart2.

devzone.nordicsemi.com/.../4604.devicetree_5F00_generated.h

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Sigurd Hellesvik — Fri, 20 Mar 2026 09:59:55 GMT

I need it specifically for the failed build.

This is because I can check for this:

"/home/santos/ncs/v3.0.2/zephyr/include/zephyr/device.h:96:41: error: '__device_dts_ord_148' undeclared (first use in this function); did you mean '__device_dts_ord_108'?"

And specifically number 148 in your the generated devicetree file.

However, the numbers change slightly when you remove the UART, so I need it as is in the failing case.

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Thu, 19 Mar 2026 15:03:28 GMT

You're right about that.

But I can't change my project right now, anyway.

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Thu, 19 Mar 2026 15:01:52 GMT

Thanks for your replay, Sigurd.

That is my /build/<PROJECT>/zephyr/include/generated/zephyr/devicetree_generated.h without
"

&uart2 {

status = "okay";

current-speed = <115200>;

pinctrl-0 = <&uart2_default>;

pinctrl-1 = <&uart2_sleep>;

pinctrl-names = "default", "sleep";

};

devzone.nordicsemi.com/.../4010.devicetree_5F00_generated.h

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

EverlastingVeal — Thu, 19 Mar 2026 13:07:47 GMT

I meant that you should use only one SPI instance instead of SPI3 and SPI4 (assuming these two are for sensors or peripherals) - SPI is a protocol that enables multiple peripherals with GPIO control on same 3 wire data route by using different GPIOs as CS. I think the issue is NUS competing with the core UART (one used for logs/printk/ other core functionalities)

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Sigurd Hellesvik — Thu, 19 Mar 2026 12:33:27 GMT

Hi,

Can you post build/<PROJECT>/zephyr/include/generated/zephyr/devicetree_generated.h?

Regards,
Sigurd Hellesvik

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

Luis Santos — Thu, 19 Mar 2026 12:22:42 GMT

Thanks for the update, u/EcerlastingVeal.

What do you mean when you said "can you consolidate SPI instance"?

One strange thing is that even when I tried to just create a UART2 instance without assigning it to NUS, I got the same error.

chosen {

// nordic,nus-uart = &uart2;

};

&uart2 {

status = "okay";

current-speed = <115200>;

pinctrl-0 = <&uart2_default>;

pinctrl-1 = <&uart2_sleep>;

pinctrl-names = "default", "sleep";

};

&pinctrl {

uart2_default: uart2_default {

group1 {

psels = <NRF_PSEL(UART_TX, 1, 12)>,

<NRF_PSEL(UART_RTS, 1, 14)>;

};

group2 {

psels = <NRF_PSEL(UART_RX, 1, 10)>,

<NRF_PSEL(UART_CTS, 1, 7)>;

bias-pull-up;

};

uart2_sleep: uart2_sleep {

group1 {

psels = <NRF_PSEL(UART_TX, 1, 12)>,

<NRF_PSEL(UART_RX, 1, 10)>,

<NRF_PSEL(UART_RTS, 1, 14)>,

<NRF_PSEL(UART_CTS, 1, 7)>;

low-power-enable;

};

}

RE: Issue building NUS with UART on nRF5340 (APP_CORE)

EverlastingVeal — Wed, 18 Mar 2026 22:40:36 GMT

Usually when no configuration step for pic radio happens to me is because something went wrong earlier. I also think that the amount of instances you're using isn't very good practice since the only remaining UART instance is also used for core functionalities while you try to assign it to the NUS.

can you consolidate SPI instances?