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]

Hello Hieu,

Just a recap of my debugging status.  Now I am 100% sure the bootup message from the 

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

specified in the nrf5340dk_nrf5340_cupapp.overlay is actually came from the NetCore!!!!!!

Notice the overlay file  cupapp for the AppCore.

I added one line of code in zephyr/samples/bluetooth/hci_rpmsg/src/main.c

printk("Hello hci_rpmsg child from NetCore\n");    // <<--------------- Added message !!!

and now I see the message from the NetCore from the UART pins for the AppCore !!??

*** 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
*** Booting Zephyr OS build v3.1.99-ncs1 ***
Hello hci_rpmsg child from NetCore

It is a little progress, but at least I verified the assumption of the AppCore message is actually came from NetCore !!   The next step is to understand. this rerouting/forwarding configuration, so eventually I can send to AppCore UART message to 

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

The problem is related to kernel configuration at the very very early beginning in the sw build process, so I will need help to solve.  It is a run time bug that I can use a debugger to step thru the code.

Thanks for helping.

void main(void)
{
	int err;
	const struct device *hci_ipc_instance =
		DEVICE_DT_GET(DT_CHOSEN(zephyr_bt_hci_rpmsg_ipc));

	/* incoming events and data from the controller */
	static K_FIFO_DEFINE(rx_queue);

	printk("Hello hci_rpmsg child from NetCore\n");

	LOG_DBG("Start");

[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