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;
        };
    };
};

[Hieu]

Hi,

Sorry for being unable to keep on with the quick response. I broke my build environment somehow, and also had to learn a bit more on this topic.

Anyway, things works now. What I observe is that if I simply disable UART0 using just .overlay file, the build won't even succeed, because the Kconfig CONFIG_CONSOLE_UART depends on it. If I turn that Kconfig off, UART console stopped completely as you would expect.

If you are having a custom board, I believe the proper way would be to create your own .dts file for it rather than making .overlay to morph the nRF5340DK into your board.

Best regards,
Hieu 

[jchan12345]

Hello Hieu, 

Thanks again for your quick response.  Just a follow up question.  Would Nordic fix this hard-coded bug which broke the overlay function or it would require Zephyr Project to fix it ? 

Thanks, 

JC

[Hieu]

Hi JC,

I think there is just a misunderstanding here that makes you see it as a bug. It is not really one.

Device Tree specification, which the .dts and .overlay files are about, describes the hardware to the toolchain.
Kconfig is to configure the software libraries and features used by your project.

With that in mind, let's look at it again. We disabled UART in the hardware description through the overlay file.
However, UART Console remains enabled in the Kconfig through default settings in nrf5340dk_nrf5340_cpuapp_defconfig.

When the software library is built, the feature found that its necessary backend reference is not available. Of course the build process would complain, right?

As an experiment, I keep UART0 disabled, and turned UART1 on instead and provided it to the UART Console feature. It works!

/ {

	chosen {
		zephyr,console = &uart1;
		zephyr,shell-uart = &uart1;
		zephyr,uart-mcumgr = &uart1;
		zephyr,bt-mon-uart = &uart1;
		zephyr,bt-c2h-uart = &uart1;
	};
};

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

&uart1 {
	status = "okay";
	compatible = "nordic,nrf-uarte";
	current-speed = <115200>;
	
	// Map UART1 to UART0 default pins
	pinctrl-0 = <&uart0_default>;
	pinctrl-1 = <&uart0_sleep>;
	pinctrl-names = "default", "sleep";
};

CONFIG_UART_CONSOLE=y

I hope this clears thing up for you. I do agree that a lot of these setups are not very intuitive and obvious though. For example, I wouldn't notice CONFIG_UART_CONSOLE is enabled by nrf5340dk_nrf5340_cpuapp_defconfig if I wasn't using the VS Code Extension and see the GUI tooltips that pointed it out.

If you are interested in getting a better grasp at these things, I recommend you to take a look at this course we created to help people getting started with the nRF Connect SDK: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/

Best regards,
Hieu

[jchan12345]

Hello Zephyr Expert, 

NCS V2.1.0 Zephyr peripheral_lbs example hard-coded UART0 console to 

rts: <&gpio0 19>

tx: <&gpio0 20>

cts: <&gpio0 21>

rx: <&gpio0 22>

so it Can't be overwritten by overlay file nrf5340dk_nrf5340_cuppapp.overlay

and it Can't be changed by editing nrf5340_cupapp_commmon.dts

and Can't be changed by editing nrf5340_cupapp_commmon-pinctrl.dtsi

and Can't be changed by editing nrf5340_cpuapp_peripherals.dtsi

I need to change the UART console tx pin to P1.1 and rx pin to P0.29

Any suggestion ??

Thanks,

JC

 

[jchan12345]

Now I can change the UART console tx pin to P1.1 and rx pin to P0.29 by editing the nrf5340_cupapp_commmon-pinctrl.dtsi.  However, the console stop printing during boot up process. This is the only output from the console

*** Booting Zephyr OS build v3.1.99-ncs1 ***

then it stopped printing.  The debugger still running and stepping through printk(), but nothing printing to console.  Something modified the pin configuration back to the original pin configuration ???  Digging deeper into this problem

[Hieu]

Hi JC,

Glad to know you are able to change the pin now. I was a little worried that I would not be able to verify the solution I give you, as I don't have an external UART board right now.

The line of log you observed is printed by the bootloader. It has its own firmware and pin configuration. Therefore it is not affected by the change you made and still print a log out.

If you wish to turn off bootloader logging, you can refer to this DevZone Q&A:  MCUboot - disabling uart console print log 

Once again, I must remind you that changing .dtsi, .dts, and .overlay file is not the correct way to configure your custom board. I strongly advise you to create a .dts file for your own board, referencing the nrf53_cpuap_***.dts* files.

Best regards,

Hieu

[jchan12345]

It seems the bootloader read the nrf5340dk_nrf5340_cuppapp.overlay file with no problem, so the bootloader can print *** Booting Zephyr OS build v3.1.99-ncs1 *** message.  However,  zephyr may have problem using the nrf5340dk_nrf5340_cuppapp.overlay, so it is still using pin configured for nrf5340dk.  The zephyr application is running with the debugger.  Just with no output to uart console.  Still debugging this problem.  Any clue and suggestion will be appreciated.

[jchan12345]

There are some UART0 registers is the data sheet.   Going thru functions call stack to find out which function call is making some changes ??

19 0x41013000 UARTE UARTE0 NS NA Universal asynchronous receiver/transmitter

0x50008000 0x40008000 UARTE UARTE0 : S UARTE0 : NS US SA Universal asynchronous receiver/tra

[Hieu]

Hi JC,

I am not sure we are on the same page at the moment. Here is my current understanding about your current situation:

• You currently have UART0 with the following pins:
  • TX at P1.01
  • RX at P0.29
  • You are using .overlay file to achieve this
  • You do see the log *** Booting Zephyr OS build v3.1.99-ncs1 ***
  • You do not see the application's UART console/printk
• You are still testing on the nRF5340 DK
• You are not using UART flow control (no mention of RTS/CTS)

If there is anything wrong above, please correct me.

Assuming my understanding above is correct, below I will give some facts that might help

• When the PC connects to the nRF5340 DK, it does not directly connect to the nRF53 chip under test.
  It connects to the Virtual COM (VCOM) ports on the Interface MCU.
  On nRF5340 DK revision 1, there are three VCOM ports.
  On nRF5340 DK revision 2, there are two VCOM ports. (*1)
  For more information, refer to the links above and also the schematic files.
  
  
• The application examples that use UART to log, out of the box, are almost always configured to connect to one same VCOM port. In the schematic, this is named VCOM2.
  
  To talk to VCOM2, your UART pins must be configured as follow:
  
  • TX at P0.20
  • RX at P0.22
  • If using flow control, RTS at P0.19
  • If using flow control, CTS at P0.21
    
    
• Unfortunately there are no VCOM ports connect to the pins you are using (P0.01 and P0.29).
  If you wish to see UART console with those pins, you will have to rely on an UART-to-USB board. (*2)
  
  
• The bootloader was not affected by the application .overlay file. That is why the bootloader can use the default pin and send data to the Virtual COM port, and you can see *** Booting Zephyr OS build v3.1.99-ncs1 ***
  
  
• Your application was affected by the application .overlay file. That is why the application is sending data to P1.1 and P0.29, not to the Virtual COM port. Therefore you don't see any log from the application printk.

I hope the above information is sufficient for you to understand what is going on. If you are interested, be low I will also expand on some extra things you can do.

Notes (more advanced "ways to discover" the problem):

• (*1): All nRF5340 DKs also support one/two more Virtual COM port. While they cannot be used to test your exact configuration, they can be used to test if your direction is correct.
  
  By design, the port named VCOM0 on the schematic is connected to the default pins of UART1. This can be used to prove that the way you are configuring new UART pins works, without the need of an extra UART-to-USB board.
  
  Unfortunately, by default, UART1 along with its default pins are given to the Network Core. This configuration is in nrf5340_cpuapp_common.dts.
  

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

  
  Therefore you would have to perform a few extra steps.
  
  
  • Disable the nrf-gpio-forwarder in your overlay/dts file
    
    
  • Disable serial functionalities in the network core
    • For example, by creating Kconfig file <Project Root>/child_image/hci_rpmsg.conf, in which you write CONFIG_SERIAL=n
    • If you create the file as above, remember to make a pristine build so that the toolchain can detect the new file
      
      
  • Configure your UART peripheral to this 2nd VCOM port
    • TX at P1.01
    • RX at P1.00
    • RTS at P0.11
    • CTS at P0.10
      
      
• (*2): You can rewire the DK to your desire pins by disconnecting/connecting a few solder bridges and wires.
  • This will change your board completely, and you do risk breaking it. 
  • If you chose this method, please do so fully aware of and owning the risk.
  • If you modified the board successfully, always keep that in mind to prevent confusions in future development and support cases.

Best regards,

Hieu