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

[jchan12345]

Hello Hieu,

I am a bit confused too, so I step back to check on my build tool and test setup first.

There are three virtual com from nRF5340DK

When I run peripheral_lbs  onnRF5340DK.  One com port shows the the output from the AppCore

*** Booting Zephyr OS build v3.1.99-ncs1 ***
Starting Bluetooth Peripheral LBS example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fc8
I: data wra: 0, 2c
I: No ID address. App must call settings_load()
Bluetooth initialized
Advertising successfully started

and another com port shows

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

and I think this may be from the NetCore

I am back to square 0 to restart the whole debugging process slowly now.