No output to UART console when CONFIG_BT=y

[jchan12345]

There is no output to UART console when I set CONFIG_BT=y in prj.conf

peripheral_lbs sample project in ncs V2.0.2 can't printk anything.  

[Hieu]

Hi,

Unfortunately I cannot reproduce your issue.
I just now tried a brand new application based on the NCS v2.0.2 peripheral_lbs example on both the nRF52DK and the nRF5340DK, and for both printk() worked and I got data on a Serial Port.
I really don't think CONFIG_BT=y would break UART console, that would really not make sense.

Are you developing on a Development Kit or on your custom board?

By the way, as you requested, the prj.conf used to test:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_LBS"

# Enable the LBS service
CONFIG_BT_LBS=y
CONFIG_BT_LBS_POLL_BUTTON=y
CONFIG_DK_LIBRARY=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

Best regards,
Hieu

[jchan12345]

Hello Hieu, 

Thanks for your quick response.  I have one more request.  Would you use the nrf5340dk_nrf5340_cpuapp.overlay    file to disable to UART console and see if you can still receive output.?  My problem seems to be complicated.  The UART on nRF5340DK always work even if I intentionally disable the UART or assign different TX and RX pins.   I am trying to make sure the overlay file can change the behavior first, then I will make correct adjustment on my own custom board. 

I have more problem on my custom board, but one thing at a time.  I want to get the UART working in different configuration/overlay first.

Thanks again.

My own. nrf5340dk_nrf5340_cpuapp.overlay. for a different custom board, but nRF5340DK is unexpectly working fine with it, so something is wrong

I may have mistakes in the overlay file

&uart0 {
    //status = "okay";
    status = "disabled";
	label = "UART_0";
	current-speed = <115200>;		// 115200
    pinctrl-0 = <&uart0_default_alt>;
    pinctrl-1 = <&uart0_sleep_alt>;
    pinctrl-names = "default", "sleep";
};


&pinctrl {
    uart0_default_alt: uart0_default_alt {
        group1 {
            psels = <NRF_PSEL(UART_TX, 1, 1)>;		// P1.1 is TX
        };
        group2 {
            psels = <NRF_PSEL(UART_RX, 0, 29)>;		// P0.29 is RX
            bias-pull-up;
        };
    };
    uart0_sleep_alt: uart0_sleep_alt {
        group1 {
            psels = <NRF_PSEL(UART_TX, 1, 1)>,		// P1.1 is TX
                    <NRF_PSEL(UART_RX, 0, 29)>;		// P0.29 is RX
            low-power-enable;
        };
    };
};

[jchan12345]

By setting 

CONFIG_SERIAL=y or n in child_image/hci_rpmsg.conf 

I can see or not see *** Booting Zephyr OS build v3.1.99-ncs1 ***. on the UART console connected to my custom board running application built with overlay file nrf5340dk_nrf5340_cuppapp.overlay setting 

• TX at P1.01
• RX at P0.29

The important point is I am using overlay file for AppCore to configure the UART pins but turning on/off tx/rx data with CONFIG_SERIAL for child image which is running in the NetCore!!!!

This is the reason that I think the message *** Booting Zephyr OS build v3.1.99-ncs1 *** on my console connected to the AppCore UART is actually the bootup message from the NetCore.

Now, I can disable the NetCore UART

The next step is to configure AppCore UART to

• TX at P1.01
• RX at P0.29

Do you have any suggestion.   Thanks for your help.

 

[jchan12345]

With CONFIG_SERIAL=n in child_image/hci_rpmsg.conf, I can shut down the UART of NetCore, but setting. 

CONFIG_UART_CONSOLE=y

CONFIG_SERIAL=y

in the prj.conf does not send any bootup message from the AppCore to 

• TX at P1.01
• RX at P0.29

[jchan12345]

Hell Hieu,

Beside working on my custom board, I also try to learn and compare with the nRF5340DK board.  To start with a new peripheral_lbs project with NCS V2.1.0.  I got the following warning when creating it with nRF Connect SDK

warning: UART_CONSOLE (defined at drivers/console/Kconfig:43) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL (=n), SERIAL_HAS_DRIVER (=n). See
docs.zephyrproject.org/.../kconfig.html and/or look up UART_CONSOLE in
the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration
Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

Just following very lead related to UART like old fashion detective work.

Did you see this warning when creating the application?

Thanks,

JC

[jchan12345]

Never mind.  The warning: UART_CONSOLE (defined at drivers/console/Kconfig:43) was assigned the value 'y' but got the value 'n'.

is related to 

CONFIG_SERIAL=n

in hci_rpmsg.conf

[Hieu]

Hi JC,

Firstly, it is indeed keep digging and experimenting sometimes. In an ideal world we would fully understand the setup and know exactly why the system behave like we see it. But as NCS is very complex, the detective work as you say is what we have to do sometimes.

---

I have also observed that the .overlay file is affecting the bootloader; and also the child_image prj.conf that I suggested to you might not be doing what I expected it to be.

Another thing is that your custom configuration, TX on P1.01, does connect to one VCOM port, the one named VCOM0 on the schematic.

I'm very sorry for having given you incorrect information and missing the VCOM fact, which might have caused you lost time.

---

As I am out of office tomorrow, I will get back on Friday/Monday with the following:
- More accurate information on the relations between the bootloader and the .overlay file
- How to ensure NetCore is not using the UART peripheral, or at least P1.01 which you need.
- The answer to your latest question, about the warning of Kconfig being reassigned.

---

For today, I have been created and verify a step by step experiment to give both of us a clear picture of what is logging to where. 

Before you try, please setup your environment as follow:

- Open all three COM ports your DK provide as you experiment. You might need an extra terminal program such as PuTTy.
- Make sure to revert all changes made to .dts and .dtsi files in your SDK. Might be best to install a fresh one.
- On a clean new copy of the example

Here are the experiment steps, with the necessary overlay code and the expected observation:

0. Run a fresh run with an empty overlay file

You should observed both bootloader and application logging on one port.
That is VCOM2.

1. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Not disabling GPIO forwarder.

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

You should observed only bootloader logging on a different COM port.
That is VCOM0.

2. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Disabling GPIO forwarder.

/ {
	gpio_fwd: nrf-gpio-forwarder {
		compatible = "nordic,nrf-gpio-forwarder";
		status = "disabled";
		uart {
			gpios = <&gpio1 1 0>, <&gpio1 0 0>, <&gpio0 11 0>, <&gpio0 10 0>;
		};
	};
};

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

You should observed both bootloader and application logging on VCOM0

3. UART0 with TX on P1.01, RX on P0.29 (your configuration). Disabling GPIO forwarder.

/ {
	gpio_fwd: nrf-gpio-forwarder {
		compatible = "nordic,nrf-gpio-forwarder";
		status = "disabled";
		uart {
			gpios = <&gpio1 1 0>, <&gpio1 0 0>, <&gpio0 11 0>, <&gpio0 10 0>;
		};
	};
};

&pinctrl {
	custom_default: c {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 1)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 29)>;
			bias-pull-up;
		};
	};

	custom_sleep: custom_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 1)>,
				<NRF_PSEL(UART_RX, 0, 29)>;
			low-power-enable;
		};
	};
};

&uart0 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&custom_default>;
	pinctrl-1 = <&custom_sleep>;
	pinctrl-names = "default", "sleep";
};

You should observed both bootloader and application logging on VCOM0.

4. UART0 with TX on P1.01, RX on P0.29 (your configuration). NOT disabling GPIO forwarder.

/ {
	gpio_fwd: nrf-gpio-forwarder {
		compatible = "nordic,nrf-gpio-forwarder";
		status = "disabled";
		uart {
			gpios = <&gpio1 1 0>, <&gpio1 0 0>, <&gpio0 11 0>, <&gpio0 10 0>;
		};
	};
};

&uart0 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&custom_default>;
	pinctrl-1 = <&custom_sleep>;
	pinctrl-names = "default", "sleep";
};

You should observed only bootloader logging on VCOM0.

---

I hope this helps.

Best regards,

Hieu

[jchan12345]

Hello Hieu,

Thanks for the detailed instructions and help.  For your following action plan

1. - More accurate information on the relations between the bootloader and the .overlay file
2. - How to ensure NetCore is not using the UART peripheral, or at least P1.01 which you need.
3. - The answer to your latest question, about the warning of Kconfig being reassigned.

Question 2 is the most important for me.

Question 3 is related to setting CONFIG_SERIAL=n in child_image\hci_rpmsg.   It is not happy and gives out warning when NetCore UART is being shutdown by CONFIG_SERIAL=n, so it is not freely reconfigurable?  Does it has to be always on and come out at the default pins for UART0, ...etc ??

By the way, I have tried UART1.  The remap of UART1 to UART0 of the AppCore

• TX at P1.01
• RX at P0.29

has no problem, but it still outputs messages from NetCore.  I got the same message

*** Booting Zephyr OS build v3.1.99-ncs1 ***
Hello hci_rpmsg child from NetCore
*** Booting Zephyr OS build v3.1.99-ncs1 ***
Hello hci_rpmsg child from NetCore

So changing to UART1 of AppCore does not get the UART message from the AppCore.

I will try your experiment sand suggestions

Thanks,

JC

.  

[jchan12345]

Hello Hieu,

Here is the result of test according to your instructions.

0. Run a fresh run with an empty overlay file

"You should observed both bootloader and application logging on one port.
That is VCOM2."

I saw UART output from AppCore and NetCore

[jchan12345]

1. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Not disabling GPIO forwarde

You should observed only bootloader logging on a different COM port.

That is VCOM0.

I got same output as case 0.

[jchan12345]

2. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Disabling GPIO forwarder.

You should observed both bootloader and application logging on VCOM0

I did not the uart output from the NetCore now, so I think the UART output from NetCore is not forwarded

[jchan12345]

3. UART0 with TX on P1.01, RX on P0.29 (your configuration). Disabling GPIO forwarder.

You should observed both bootloader and application logging on VCOM0.

Now I got the AppCore UART output on the right terminal.  Disable the GPIO forwarder is the secret.