No output to UART console when CONFIG_BT=y

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.  

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

  • 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

  • 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

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

  • 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

  • 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

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

Children
  • 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.

  • You read my mind and I was exactly in that situation.  Thanks for your info which helps directing my thought on the debugging process.  Let me regroup with your suggestions first before moving forward

  • The message *** Booting Zephyr OS build v3.1.99-ncs1 *** coming out at 

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

    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 

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

    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 

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

    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 

    CONFIG_SERIAL=n
    CONFIG_USE_SEGGER_RTT=y
    CONFIG_RTT_CONSOLE=y
    CONFIG_UART_CONSOLE=n
    in prj.conf
    and I got some blue tooth messages from the AppCore
    Starting Zombie Bluetooth Peripheral LBS example
    I: 2 Sectors of 4096 bytes
    I: alloc wra: 0, fd0
    I: data wra: 0, 1c
    I: No ID address. App must call settings_load()
    Bluetooth initialized
    Advertising successfully started
    and I got *** Booting Zephyr OS build v3.1.99-ncs1  *** from UART with 
    • TX at P1.01
    • RX at P0.29

    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

Related