How to Separate Logging and Serial Communication on Different VCOMs (nRF5340)

RE: How to Separate Logging and Serial Communication on Different VCOMs (nRF5340)

Yash48 — Thu, 27 Feb 2025 17:21:50 GMT

Hi Edvin,

Thank you so much for your detailed response! Your explanation and the recommended configurations worked perfectly.

I was able to successfully separate logging (UARTE0) and serial communication (UARTE1).

Modifying the .overlay file and prj.conf as per your instructions ensured proper log isolation and serial functionality.

I also wanted to ask about the impact of this line in the .overlay file:

/delete-node/ &gpio_fwd;

What exactly does this change in terms of GPIO behavior? Does it completely stop GPIO forwarding from the network core, or are there any cases where some pins might still be affected?

I appreciate your advice on using RTT Logging as well—it’s definitely useful for development. I’ll keep it in mind for future debugging needs.

Thanks again for your guidance! This was extremely helpful.

Best regards,

Yash

RE: How to Separate Logging and Serial Communication on Different VCOMs (nRF5340)

Edvin — Thu, 27 Feb 2025 14:13:32 GMT

Both. Sorry for being a bit short in my previous reply. I didn't have time to look up all the configs. But again, if this is only for development, save yourself some time and use RTT Logging.

[quote user="Yash48"]Disabling Network Core Logging & Stopping Pin Forwarding[/quote]

[quote user="Yash48"]Should I modify the .overlay file, prj.conf, or both?[/quote]

Both. .overlay to disable and enable the correct UARTs, and Kconfig (prj.conf) to enable disable logging.

[quote user="Yash48"]How should I configure the .overlay file and prj.conf to ensure logs stay on UARTE0 while UART1 is used solely for communication?[/quote]

UARTE0 will be used for logging. I don't remember exactly which setting it is, but it is the one linked to console in the board files (nrf5340dk_nrf5340.dts/dtsi).

[quote user="Yash48"]Should I modify the zephyr,console or zephyr,shell-uart settings?[/quote]

console.

[quote user="Yash48"]

What additional configurations (e.g., Kconfig, DTS) are needed to ensure UART1 does not interfere with VCOM2?

[/quote]

you should never modify the dts/dtsi files directly. If you find something in these files that you want to change, copy that section, and paste it into <board_name>.overlay, and edit it there.

So, what you actually need to do. If you look in nrf5340_cpuapp_common.dtsi:

/ {

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,bt-c2h-uart = &uart0;
		zephyr,bt-hci = &bt_hci_ipc0;
		nordic,802154-spinel-ipc = &ipc0;
		zephyr,ieee802154 = &ieee802154;
	};

Here you can see that the console is pointing to uart0, so whatever you configure as the UART0 pins will be the ones that will output the log messages. This is set in nrf5340_cpuapp_common-pinctrl.dtsi:

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 20)>,
				<NRF_PSEL(UART_RTS, 0, 19)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 22)>,
				<NRF_PSEL(UART_CTS, 0, 21)>;
			bias-pull-up;
		};
	};

	uart0_sleep: uart0_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 20)>,
				<NRF_PSEL(UART_RX, 0, 22)>,
				<NRF_PSEL(UART_RTS, 0, 19)>,
				<NRF_PSEL(UART_CTS, 0, 21)>;
			low-power-enable;
		};
	};
};

Paste this snippet into your nrf5340dk_nrf5340_cpuapp.overlay if you want to change the pins. Also create this for uart1_default and uart1_sleep.

To disable the GPIO forwarding, you need to add this line to your .overlay file::

/delete-node/ &gpio_fwd;

Then set up uart0 and uart1 by enabling them in .overlay. The uart0 is enabled by default, but you can add uart1 like this:

&uart1 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart1_default>;
	pinctrl-1 = <&uart1_sleep>;
	pinctrl-names = "default", "sleep";
};

And you can add this snippet as well, so that you have something to point to in your application:

/ {
	chosen {
        nordic,app-uart = &uart1;
	};
};

And then you can use it in your application, pretty much like it is done in the NCS\nrf\samples\bluetooth\peripheral_uart, but in main.c, instead of:

static const struct device *uart = DEVICE_DT_GET(DT_CHOSEN(nordic_nus_uart));

you can use:

static const struct device *uart = DEVICE_DT_GET(DT_CHOSEN(nordic_app_uart));

You can call it whatever you like. It doesn't need to be "nordic,app-uart", but remember that all "-" and "," will be replaced with "_" in your .c files.

Best regards,

Edvin

RE: How to Separate Logging and Serial Communication on Different VCOMs (nRF5340)

Yash48 — Wed, 26 Feb 2025 17:08:26 GMT

Hello Edvin,

Thank you for your response. I have made the following configurations to separate logging and serial communication:

Current Configuration:

Device Tree Overlay (UART1 Enabled for Serial Communication):
&uart1 { status = "okay"; };

Default UART1 Configuration:
uart1: arduino_serial: uart@9000 { compatible = "nordic,nrf-uarte"; reg = < 0x9000 0x1000 >; interrupts = < 0x9 0x1 >; status = "okay"; current-speed = < 0x1c200 >; pinctrl-0 = < &uart1_default >; pinctrl-1 = < &uart1_sleep >; pinctrl-names = "default", "sleep"; }; uart1_default: uart1_default { group1 { psels = <NRF_PSEL(UART_TX, 1, 9)>, <NRF_PSEL(UART_RTS, 1, 11)>; }; group2 { psels = <NRF_PSEL(UART_RX, 1, 8)>, <NRF_PSEL(UART_CTS, 1, 10)>; bias-pull-up; }; };

Issue 1: UART1 Not Receiving Data

I have connected an external USB-to-UART bridge to UART1.
However, when I send data from the external UART device, nothing is received in Zephyr.
My UART1 interrupt-based handler does not trigger on incoming data.

UART Handling:
#include <zephyr/kernel.h> #include <zephyr/drivers/uart.h> #include <zephyr/sys/printk.h> #define BUFFER_SIZE 526 #define UART_NODE DT_NODELABEL(uart1) static const struct device *uart_dev = DEVICE_DT_GET(UART_NODE); static char command_buffer[BUFFER_SIZE]; static int buffer_index = 0; static volatile bool command_ready = false; void uart_callback(const struct device *dev, void *user_data) { uint8_t c; printk("DEBUG: UART Callback\n"); while (uart_irq_update(dev) && uart_irq_rx_ready(dev)) { if (uart_fifo_read(dev, &c, 1) == 1) { printk("DEBUG: Received Char: %c (ASCII: %d)\n", c, c); if (c == '\n' || c == '\r') { if (buffer_index > 0) { command_buffer[buffer_index] = '\0'; command_ready = true; } } else if (buffer_index < BUFFER_SIZE - 1) { command_buffer[buffer_index++] = c; } else { buffer_index = 0; // Reset on overflow } } } } int uart_init() { if (!device_is_ready(uart_dev)) { printk("ERROR: UART device not ready!\n"); return -1; } uart_irq_callback_set(uart_dev, uart_callback); uart_irq_rx_enable(uart_dev); printk("UART Initialized\n"); return 0; }

Debugging Steps Tried:

Checked with device_is_ready(uart_dev), and UART1 is initialized successfully.
Verified the external USB-to-UART bridge works with other devices.
Confirmed UART1 TX/RX pins are set correctly.

In this case if i use the UART0(VCOM1) then it work fine .

Issue 2: Unexpected Loopback Between VCOM2 and UART1

When I send data to VCOM2, it appears on UART1 (external USB-to-UART).
When I send data to UART1, it appears on VCOM2

Questions:

Disabling Network Core Logging & Stopping Pin Forwarding
- How exactly do I disable logging on the network core and stop pin forwarding?
- Should I modify the .overlay file, prj.conf, or both?
Configuring UARTE0 for Logs & UART1 for Communication
- How should I configure the .overlay file and prj.conf to ensure logs stay on UARTE0 while UART1 is used solely for communication?
Preventing GPIO Conflicts with the Network Core
- If the network core is using the same GPIOs by default, how can I prevent conflicts?
- Should I modify the zephyr,console or zephyr,shell-uart settings?
- Is there a way to stop pin forwarding to the network core while keeping the application core logging enabled?
Additional Configuration Considerations
- What additional configurations (e.g., Kconfig, DTS) are needed to ensure UART1 does not interfere with VCOM2?
- Are there any nrfjprog or J-Link debugger settings that need to be changed?

Could you guide me on the correct configurations to fully separate logging and serial communication in both cases—one without an external USB-to-UART adapter and one with it connected?

Thanks in advance for your help!

RE: How to Separate Logging and Serial Communication on Different VCOMs (nRF5340)

Edvin — Wed, 26 Feb 2025 14:50:03 GMT

Hello,

The two COM ports on the DK are the two UARTs that the nRF5340 uses for logging by default. One for the application core, and one for the network core. So the one you are saying just logs boot information, that is probably the network core logging.

[quote user=""]Is there an internal J-Link OB forwarding mechanism that could be causing this issue?[/quote]

The debugger is hard wired to specific GPIOs that are used by the app core and network core by default. They are listed on the back of the DK. They are named RTS TXD CTS and RXD.

What you can do is to disable logging on the network core, stop the pin forwarding to the network core, and control these as a separate UART on the app core.

[quote user=""]Are there any Zephyr configurations or Nordic-specific settings required to properly separate logs and serial communication?[/quote]

Yes. The logging is by default done on the first UART instance, i.e. UARTE0. So if you set up a different UART for serial communication you should be fine. Just make sure that they use the same GPIOs as the network core use by default.

[quote user=""]What is the best way to ensure logs stay on VCOM1 and serial communication happens only on VCOM2?[/quote]

These are hard-wired to particular pins, so they will not change.

However, if you want to use UART for serial communication and at the same time monitor logs, another, perhaps easier option, is to use RTT Logging. This kind of log doesn't require it's own GPIOs. It uses a RAM buffer to write the log, and the debugger reads this RAM buffer. If you are interested, this is the way it is done in the NCS\nrf\samples\bluetooth\peripheral_uart sample. To monitor the LOG, you can either open the log in VS Code by connecting the RTT viewer there, or you can use a standalone RTT viewer, such as the one provided by JLink. (from segger.com).

Best regards,

Edvin