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.
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.
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
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;
};
};
};
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
Hello Hieu,
Just a recap of my debugging status. Now I am 100% sure the bootup message from the
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
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");
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
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
.
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
1. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Not disabling GPIO forwarde
That is VCOM0.
I got same output as case 0.
1. UART0 with TX on P1.01, RX on P1.00 (VCOM0/UART1 ports). Not disabling GPIO forwarde
That is VCOM0.
I got same output as case 0.