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;
};
};
};
The message *** Booting Zephyr OS build v3.1.99-ncs1 *** coming out at
may be from the NetCore and I am looking for the output from AppCore. Let me try your suggestion to disable the UART at NetCore first.
The message *** Booting Zephyr OS build v3.1.99-ncs1 *** coming out at
is actually from the NetCore. I got the output of AppCore using RTT, so my application is running fine. It is just somehow the UART pins of NetCore are connected as specified in the overlay file for AppCore!!!!
I will need your guidance to re-route the AppCore UART to
so I don't need to use RTT for it.
Anyway, it is interesting that the UART of NetCore is actually mapped to that for the NetCore. However, it is better to document it and print messages from AppCore and NetCore. Both print the same message*** Booting Zephyr OS build v3.1.99-ncs1 *** at the beginning. Hard to tell if it has been re routed.
Thanks for your great help!!!
Let me clarify. I am able to use my custom board RTT for the AppCore with
What I need is to flip the RTT and UART. With AppCore messages come out from UART and NetCore messages come out from RTT.
My custom board has only one UART, so I use it for the AppCore with shell commands.
Need to re-route with different configuration.
Thanks for helping.
JC
By setting
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
Do you have any suggestion. Thanks for your help.
With CONFIG_SERIAL=n in child_image/hci_rpmsg.conf, I can shut down the UART of NetCore, but setting.
With CONFIG_SERIAL=n in child_image/hci_rpmsg.conf, I can shut down the UART of NetCore, but setting.
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,
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.
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