DTM (direct test mode) connect fail in ncs v2.2.0

[Felix Shih]

HI,

I build project direct_test_mode and empty_app_core and connect to PC softwarre DTM v2.

If build from ncs v1.9.1, it connect ok to show standby. but if build from ncs v2.2.0, DTM show NG.

Can you help me to verify it? something wrong?

[Håkon Alseth]

Hi,

 

Which nRF device are you compiling for?

Does DTM work in nRF connect for desktop application?

 

Kind regards,

Håkon

[Felix Shih]

Hi,

1) HW is nRF5340-DK, UART is RX(P1.00), TX(P1.01)

2) I just test with nRF connect for Desktop still fail in ncs v2.2.0 image

[Felix Shih]

Hi, 

I follow your suggestion to build DTM in ncs v2.2.0, but test fail in our HW.

Our HW structure is as following,

nRF5340 UART (P1.00, P1.01) connect to another MCU (as UART transparent role),

can I use ncs v2.2.0 DTM? or I just can use ncs v1.9.1 DTM?

You said "As a workaround, can you try to select the application core COM-port?" before.

[Håkon Alseth]

Hi,

 

My apologies, but there are more steps that needs to be included for DTM in ncs v2.2.0 to behave similar to previous SDK versions.

Håkon Alseth said:

You can disable the remote_shell, and use empty_app_core (as previous) by setting this

You will need to change this section:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/direct_test_mode/boards/nrf5340dk_nrf5340_cpunet.overlay#L7-L13

to:

&uart0 {
	status = "okay";
	compatible = "nordic,nrf-uarte";
	current-speed = <19200>;
};

 

And also change the board .conf file:

https://github.com/nrfconnect/sdk-nrf/blob/v2.2.0/samples/bluetooth/direct_test_mode/boards/nrf5340dk_nrf5340_cpunet.conf

 

To only include this line:

CONFIG_NCS_SAMPLE_REMOTE_SHELL_CHILD_IMAGE=n

 

Unfortunately, this does not automatically include the empty_app_core project, so that must also manually be flashed first.

Felix Shih said:

nRF5340 UART (P1.00, P1.01) connect to another MCU (as UART transparent role),

As long as your external mcu forwards byte for byte, that should in theory work. One thing that will be different is the timing of the bus communication in your scenario.

Kind regards,

Håkon

[Felix Shih]

Hi, 

I follow your steps to build DTM in ncs v2.2.0, it seems to work. DTM v2 can connect to nRF5340 and show "STAND BY" now.

I also got the following problem message in VS code, is it ok?

\projects\direct_test_mode\src/fem/Kconfig:49: error: couldn't parse 'depends on $(dt_nodelabel_has_prop,nrf_radio_fem,chl-gpios)': macro expanded to blank string

[Håkon Alseth]

Hi,

 

This indicates that you're adding a frontend module (like nRF21540 or a generic 2-wire PA/LNA setup). Can you share the board that you're using (ie. nrf5340dk_nrf5340_cpunet for instance) and any additional .overlay files that you're including in your build?

 

Kind regards,

Håkon

[Felix Shih]

Hi,

I may made mistake in the previous build process, and I rebuild the direct_test_mode project and the problem message disappeared now.

I got the antenna pins waveform as the following, but it seems strange, P0.26 keep low.

My overlay file is:

/ {
	chosen {
		ncs,dtm-uart = &uart0;
	};
};

/* 
&uart0 {
	status = "okay";
	compatible = "nordic,nrf-ipc-uart";
	ipc = <&ipc0>;
	ept-name = "remote shell";
	current-speed = <19200>;
};
*/

&uart0 {
	status = "okay";
	compatible = "nordic,nrf-uarte";
	current-speed = < 115200 >;
};


&radio {
	status = "okay";
	/* This is a number of antennas that are available on antenna matrix
	 * designed by Nordic. For more information see README.rst.
	 */
	/* dfe-antenna-num = <12>; */
	dfe-antenna-num = <4>;
	/* This is a setting that enables antenna 12 (in antenna matrix designed
	 * by Nordic) for PDU. For more information see README.rst.
	 */
	dfe-pdu-antenna = <0x0>;

	/* These are GPIO pin numbers that are provided to
	 * Radio peripheral. The pins will be acquired by Radio to
	 * drive antenna switching.
	 * Pin numbers are selected to drive switches on antenna matrix
	 * desinged by Nordic. For more information see README.rst.
	 */
	 /* 
	dfegpio0-gpios = <&gpio0 4 0>;
	dfegpio1-gpios = <&gpio0 5 0>;
	dfegpio2-gpios = <&gpio0 6 0>;
	dfegpio3-gpios = <&gpio0 7 0>;
	*/

	dfegpio0-gpios = <&gpio0 25 0>;
	dfegpio1-gpios = <&gpio0 26 0>;
};

 

My conf file is:

#
# Copyright (c) 2021 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

#CONFIG_IPC_UART=y
#CONFIG_IPC_SERVICE=y
#CONFIG_IPC_SERVICE_BACKEND_RPMSG=y
#CONFIG_MBOX=y

#CONFIG_NRFX_DPPI=y

#CONFIG_HEAP_MEM_POOL_SIZE=4096

# Build Remote shell APP Core sample for the application core
CONFIG_NCS_SAMPLE_REMOTE_SHELL_CHILD_IMAGE=n


CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y

DTM v2 settings:

[Håkon Alseth]

Hi,

 

I used the exact same settings as you, which corresponds with the dfegpio0 and dfegpio1 setting in the overlay file, and got this output on P0.25 and P0.26:

 

Also tested other GPIOs, and they also worked as expected. Could you try to do the same?

 

I cannot see if the type that you've selected is "1 us" or "2 us" in the CTE Info -> "Type", but I used 1 us there.

 

Kind regards,

Håkon

[Felix Shih]

Hi,

My test as follow:

1)

use 1us, P0.25, P0.26 change

use 2us, P0.26 keeps low

2) In 1us condition, it repeats (high, low) -> (low, high) -> (low, low) pattern, it lacks (high, high) combination, the waveform is correct?

[Håkon Alseth]

Hi,

 

Try expanding the time to 3 slots when using 2 us AoD slots.

It should then switch between bitwise 00/01/10/11 states.

Felix Shih said:

In 1us condition, it repeats (high, low) -> (low, high) -> (low, low) pattern, it lacks (high, high) combination, the waveform is correct?

I see now that this was lacking in my former test as well.

As you mention, it lacks the '11' combination. This will also be impacted if you extend the "Time(8us unit)" option.

 

 

Kind regards,

Håkon