Using uart0 and uart1 in the app cpu with BT enabled on the nrf5340dk?

[danielhira]

Hello, I am trying to enable the use of both uart0 and uart1 in the app cpu while also using the board as a BLE central device.

Ultimately I would like to be able to connect USB to a host PC and to use use one uart for console/logs, and the other for binary transfer. I am basing my project off the Zephyr central_gatt_write sample app (https://docs.zephyrproject.org/latest/samples/bluetooth/central_gatt_write/README.html) and I currently have console + BT working well using uart0 with the app cpu.

From what I have read it seems that uart1 is currently dedicated to the net cpu, which I do see the "*** Booting Zephyr OS build zephyr-v3.4.0-1161-gc022115edb6c ***" messages from uart1. I don't need logs from the net cpu, so I tried remapping the pins by modifying the cpu app's dtsi (https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dtsi#L164-L170) to add uart1:

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

&uart1 {
status = "okay";
current-speed = <115200>;
pinctrl-0 = <&uart1_default>;
pinctrl-1 = <&uart1_sleep>;
pinctrl-names = "default", "sleep";
};

as well as to add uart1's rts/cts to the pinctrl (github.com/.../nrf5340_cpuapp_common-pinctrl.dtsi

uart1_default: uart1_default {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 1)>,
<NRF_PSEL(UART_RTS, 0, 11)>;
};
group2 {
psels = <NRF_PSEL(UART_RX, 1, 0)>,
<NRF_PSEL(UART_CTS, 0, 10)>;
bias-pull-up;
};
};

uart1_sleep: uart1_sleep {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 1)>,
<NRF_PSEL(UART_RX, 1, 0)>,
<NRF_PSEL(UART_RTS, 0, 11)>,
<NRF_PSEL(UART_CTS, 0, 10)>;
low-power-enable;
};
};

However when I do this, I don't get any output on uart1. I am sure there are better ways to do this with an overlay file, and/or I am missing something, so I am very open to suggestions here! Again, this is ultimately what I am working towards, but I believe I have also reproduced the issue without Zephyr below if that simplifies the problem.

I believe a simpler reproduction of the issue is done by using the above pin modifications + this sample/lesson (https://github.com/NordicDeveloperAcademy/ncs-fund/blob/main/v2.x.x/lesson5/fund_less5_exer1_solution/src/main.c), but changing this line to be uart1 instead of uart0 -- https://github.com/NordicDeveloperAcademy/ncs-fund/blob/main/v2.x.x/lesson5/fund_less5_exer1_solution/src/main.c#L39. This demo produces the expected output of:

nRF Connect SDK Fundamentals Course                                                                 
Press 1-3 on your keyboard to toggle LEDS 1-3 on your development kit

Then by adding `CONFIG_BT=y` to the prj.conf and rebuilding/flashing the cpuapp, I no longer see any output on uart1.

Is this expected that by enabling BT I should no longer see output on uart1? This is with or without an image flashed on the net cpu. Do I have a core misunderstanding about using these uarts, pin mappings, and/or how the uarts interact with BT? Thanks!

[Kazi Afroza Sultana]

Hello,

When connected to a computer, the nRF5340 DK v1.0.0 emulates three virtual COM ports (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html#id40). In the default configuration, they are set up as follows:

• The first COM port outputs the log from the network core (if available).

• The second (middle) COM port is routed to the P24 connector of the nRF5340 DK.

• The third (last) COM port outputs the log from the application core.

Probably one of this COM port is used by network core when you add CONFIG_BT = y. 

You can see here https://github.com/nrfconnect/sdk-zephyr/blob/2119df306f5c9104d479f96c4c8af00857094f83/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dtsi#L108 how this is forwarded to network core.

Thanks.

BR

Kazi

[danielhira]

Hi Kazi,

Thank you for the response. A few followup questions:

• Is there a way to use the "The second (middle) COM routed to the P24 connector" to communicate with the application core without external wiring? (I see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html#nrf5340-dk-v1-0-0-com-ports mentioning adding wiring)
  • If external wiring is required, what would be the best way to route those back to the app cpu? If pin mapping is required, could you share an example overlay for accomplishing this?
• Alternatively, is there a way to re-map the pins such that gpio_fwd is able to use other GPIO pins instead of the UART ones, and if so could you please give an example of how to do this?
• Lastly, or also alternatively, is there a way to remap the pins to change "The first COM port outputs the log from the network core (if available)." such that it also outputs logs from the app cpu? If this is possible, could you please provide an example of how to do this?

Thank you,

-Daniel

[Kazi Afroza Sultana]

Hello Daniel,

I have been looking into your queries. I think your DK version is V1. If this swapping is for nRF5340 DK, it could be possible what you are asking about. Do you want to swap the COM port during runtime or in different build? I think it is on different build time. 

danielhira said:

Is there a way to use the "The second (middle) COM routed to the P24 connector" to communicate with the application core without external wiring?

We think in this case, you need external wire. 

danielhira said:

Alternatively, is there a way to re-map the pins such that gpio_fwd is able to use other GPIO pins instead of the UART ones, and if so could you please give an example of how to do this?

You can use overlay to change this:

You could set status = ''disabled'' or change the pins that are forwarded to the network core in an overlay.

''Lastly, or also alternatively, is there a way to remap the pins to change "The first COM port outputs the log from the network core (if available)." such that it also outputs logs from the app cpu? If this is possible, could you please provide an example of how to do this?''

It is not possible as network core and application core has their different instances. These instances can not share the pins.