Problems building Direction_finding_central sample

RE: Problems building Direction_finding_central sample

Elfving — Wed, 24 Apr 2024 14:23:11 GMT

Great!

No problem 🙂

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Wed, 24 Apr 2024 11:55:25 GMT

Hi,

Thank you for your reply! I have already started my project by adding the code of board.conf to prj.conf.

I'm not sure if it's due to the version difference of VSCode or the nRF Connect for VSCode Extension Pack, but my devicetree doesn't have a dropdown menu. However, when I click on it, it actually visually opens my board.overlay.

When I click on the Devicetree Visual Editor, the dts overlay file for the board will be visible in the FILES section.

Thank you again!

Yours,

Zihao

RE: Problems building Direction_finding_central sample

Elfving — Wed, 24 Apr 2024 08:08:02 GMT

None at all, so this is something you can definitely do. Though I still find it strange how these files weren't dragged in automatically when you tried to build the project.

The one file that remains now is the dts overlay file for the board. You can have a look at the device tree drop down menu to see if it is there. If it isn't, you can try pressing "create overlay file" and creating one with the same contents.

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Wed, 24 Apr 2024 05:15:44 GMT

Hi,

Today I ran this sample successfully! Here's the thing: the nrf52833dk_nrf52833.conf in the board seems to be correct, but I don't know why it didn't work as expected. So, I copied all the code from nrf52833dk_nrf52833.conf into prj.conf. Subsequently, both the build and flash processes went smoothly, and CTE seemed fine too. Finally, I can start my project development.

At the same time, I'd like to ask, will this solution have any other adverse effects?

Thank you so much for your help, Elfving! you really helped me a lot! You are awesome!!

Yours,

Zihao

RE: Problems building Direction_finding_central sample

Zihao — Tue, 23 Apr 2024 08:28:50 GMT

Hi,

No, I built it using the default building action in VSCode. Because it seems that Nordic strongly encourages everyone to use the VSC Extension. Also, I'm really new to this, so I think the learning curve of using the command line might be higher, so I didn't use the command line...

Yours,

Zihao

RE: Problems building Direction_finding_central sample

Zihao — Tue, 23 Apr 2024 08:22:39 GMT

Hi,

Yes, there is certainly a boards folder in my project. And I find the CONFIG_BT_LL_SW_SPLIT=y in nrf52833dk_nrf52833.conf.

When I was studying the Nordic BLE course, my understanding was that board.conf takes precedence over prj.conf. Therefore, I don't understand why this setting doesn't seem to be taking effect.

You are great! I think this is important, but why would such a problem occur?

Anything helpful will be appreciated.

Yours,

Zihao

RE: Problems building Direction_finding_central sample

Elfving — Tue, 23 Apr 2024 08:03:05 GMT

Oh, and I see here that the OP built this using the command line and not using the default building action in the VSC Extension, and also made a mistake in the build command that prevents this auto-discovery of the board specific KConfig files. Did you build it in this way as well?

It is supposed to be: "west build -b nrf52833dk_nrf52833 -- -DCONF_FILE=prj.conf", when you specify "-DCONF_FILE=<file>" you must provide all the KConfig files. The other simple option is to simply build using "west build -b nrf52833dk_nrf52833".

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Elfving — Mon, 22 Apr 2024 08:51:48 GMT

That is odd.

You do definitely need CONFIG_BT_LL_SW_SPLIT to be enabled, though that should be enabled in the "nrf52833dk_nrf52833.conf" file, that should be in a "board" directory and dragged into the project when building it automatically. Could you check if you even have this boards folder in your project?

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Mon, 22 Apr 2024 07:32:38 GMT

Thank you for your reply. I apologize for the wait.

Thank you for providing the zip file, but it seems that it also didn't work...[sad]

I added CONFIG_BT_LL_SW_SPLIT=y to prj.conf, which is not set in the official samples. After that, both connection samples and connectionless samples were successfully built and flashed to nRF53833DK!

However, after flashing to my nRF52833DK, I still encountered issues with the official samples, both in connection and connectionless samples. During runtime, all these issues seem to be related to CTE configuration, resulting in err - 134.

There doesn't seem to be any abnormalities during the build process. I found some similar cases in DevZone, but they are too old and the solutions mentioned are not useful to me:

direction_finding_connectionless_tx Error: Update CTE params...failed (err -134)

Update CTE params...failed (err -134) in 'direction_finding_connectionless_tx'

I tried building both official connection and connectionless samples without any modifications, except for adding CONFIG_BT_LL_SW_SPLIT=y in the prj.conf of the connection rx and connectionless rx samples. And I tried them on ncs v2.5.1/v2.5.2/v2.6.0 but all of them resulting in err - 134.

Can you provide any assistance? Thank you!

Yours,

Zihao

RE: Problems building Direction_finding_central sample

Elfving — Thu, 18 Apr 2024 08:43:48 GMT

Hi again and sorry about the wait,

[quote user="Zihao"]

4) Actually, I modified the nRF52833DK board files before. I don't think it really matters because I just changed the gpio numbers for buttons like:

[/quote]

That change shouldn't make a difference. I tested it myself too, just in case. Though it is interesting that only the '33DK is showing this issue. Maybe there is something else that has been changed in that file that we aren't aware of. Could you try replacing it with this from my installation and see if it helps?

devzone.nordicsemi.com/.../8233.nrf52833dk_5F00_nrf52833.zip

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Tue, 09 Apr 2024 10:01:56 GMT

Thank you for your reply.
1) Well, I didn't notice anything wrong when I building and flashing other BLE samples.
2) And I updated the SDK and toolchain, but it didn't work.
3) I copied the direction finding central sample from "C:\ncs\v2.5.1\nrf\samples\bluetooth" to "D:\AoAAoD", so I felt this is few enough.
4) Actually, I modified the nRF52833DK board files before. I don't think it really matters because I just changed the gpio numbers for buttons like:

--------------------------------

buttons {

compatible = "gpio-keys";

button0: button_0 {

gpios = <&gpio0 24 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

label = "Push button switch 0";

zephyr,code = <INPUT_KEY_0>;

};

button1: button_1 {

gpios = <&gpio0 25 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

label = "Push button switch 1";

zephyr,code = <INPUT_KEY_1>;

};

button2: button_2 {

gpios = <&gpio0 11 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

label = "Push button switch 2";

zephyr,code = <INPUT_KEY_2>;

};

button3: button_3 {

gpios = <&gpio0 12 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

label = "Push button switch 3";

zephyr,code = <INPUT_KEY_3>;

};

--------------------------------

I copied the code you gave me to the overlay and dts file of nRF52833DK board but it didn't work.
However, when I try building it for nRF5340DK, it works very well. So this error occurs only build for nRF52833DK.

RE: Problems building Direction_finding_central sample

Elfving — Wed, 03 Apr 2024 07:57:16 GMT

I just tried it on my side to be sure, and it works well here. There can typically be something wrong with someone's installation, eg. files missing from the SDK. But that would typically make other samples have issues building as well. And that is not something you've noticed right?

In the toolchain manager, could you try running "update SDK" and "update toolchain" from the NCS version drop-down menu?

Maybe the path length is an issue, could you try placing it a few folders up, in eg. ncs/nrf/, and see if that makes a difference?

I assume you also haven't modified the nRF52833Dk board files, but in case those have been modified in some way, could you try building it for nRF5340DK as well?

This is the way the 52833dk dts file, and the overlay for aoa is supposed to look:

/*
 * Copyright (c) 2019 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/dts-v1/;
#include <nordic/nrf52833_qiaa.dtsi>
#include "nrf52833dk_nrf52833-pinctrl.dtsi"
#include <zephyr/dt-bindings/input/input-event-codes.h>

/ {
	model = "Nordic nRF52833 DK NRF52833";
	compatible = "nordic,nrf52833-dk-nrf52833";

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,bt-c2h-uart = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
		zephyr,ieee802154 = &ieee802154;
	};

	leds {
		compatible = "gpio-leds";
		led0: led_0 {
			gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
			label = "Green LED 0";
		};
		led1: led_1 {
			gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
			label = "Green LED 1";
		};
		led2: led_2 {
			gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
			label = "Green LED 2";
		};
		led3: led_3 {
			gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
			label = "Green LED 3";
		};
	};

	pwmleds {
		compatible = "pwm-leds";
		pwm_led0: pwm_led_0 {
			pwms = <&pwm0 0 PWM_MSEC(20) PWM_POLARITY_INVERTED>;
		};
	};

	buttons {
		compatible = "gpio-keys";
		button0: button_0 {
			gpios = <&gpio0 11 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 0";
			zephyr,code = <INPUT_KEY_0>;
		};
		button1: button_1 {
			gpios = <&gpio0 12 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 1";
			zephyr,code = <INPUT_KEY_1>;
		};
		button2: button_2 {
			gpios = <&gpio0 24 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 2";
			zephyr,code = <INPUT_KEY_2>;
		};
		button3: button_3 {
			gpios = <&gpio0 25 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 3";
			zephyr,code = <INPUT_KEY_3>;
		};
	};

	arduino_header: connector {
		compatible = "arduino-header-r3";
		#gpio-cells = <2>;
		gpio-map-mask = <0xffffffff 0xffffffc0>;
		gpio-map-pass-thru = <0 0x3f>;
		gpio-map = <0 0 &gpio0 3 0>,	/* A0 */
			   <1 0 &gpio0 4 0>,	/* A1 */
			   <2 0 &gpio0 28 0>,	/* A2 */
			   <3 0 &gpio0 29 0>,	/* A3 */
			   <4 0 &gpio0 30 0>,	/* A4 */
			   <5 0 &gpio0 31 0>,	/* A5 */
			   <6 0 &gpio1 1 0>,	/* D0 */
			   <7 0 &gpio1 2 0>,	/* D1 */
			   <8 0 &gpio1 3 0>,	/* D2 */
			   <9 0 &gpio1 4 0>,	/* D3 */
			   <10 0 &gpio1 5 0>,	/* D4 */
			   <11 0 &gpio1 6 0>,	/* D5 */
			   <12 0 &gpio1 7 0>,	/* D6 */
			   <13 0 &gpio1 8 0>,	/* D7 */
			   <14 0 &gpio0 17 0>,	/* D8 */
			   <15 0 &gpio0 19 0>,	/* D9 */
			   <16 0 &gpio0 20 0>,	/* D10 */
			   <17 0 &gpio0 21 0>,	/* D11 */
			   <18 0 &gpio0 22 0>,	/* D12 */
			   <19 0 &gpio0 23 0>,	/* D13 */
			   <20 0 &gpio0 26 0>,	/* D14 */
			   <21 0 &gpio0 27 0>;	/* D15 */
	};

	/* These aliases are provided for compatibility with samples */
	aliases {
		led0 = &led0;
		led1 = &led1;
		led2 = &led2;
		led3 = &led3;
		pwm-led0 = &pwm_led0;
		sw0 = &button0;
		sw1 = &button1;
		sw2 = &button2;
		sw3 = &button3;
		bootloader-led0 = &led0;
		mcuboot-button0 = &button0;
		mcuboot-led0 = &led0;
		watchdog0 = &wdt0;
	};
};

&adc {
	status = "okay";
};

&uicr {
	gpio-as-nreset;
};

&gpiote {
	status = "okay";
};

&gpio0 {
	status = "okay";
};

&gpio1 {
	status = "okay";
};

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

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

arduino_i2c: &i2c0 {
	compatible = "nordic,nrf-twi";
	status = "okay";
	pinctrl-0 = <&i2c0_default>;
	pinctrl-1 = <&i2c0_sleep>;
	pinctrl-names = "default", "sleep";
};

&i2c1 {
	compatible = "nordic,nrf-twi";
	/* Cannot be used together with spi1. */
	/* status = "okay"; */
	pinctrl-0 = <&i2c1_default>;
	pinctrl-1 = <&i2c1_sleep>;
	pinctrl-names = "default", "sleep";
};

&pwm0 {
	status = "okay";
	pinctrl-0 = <&pwm0_default>;
	pinctrl-1 = <&pwm0_sleep>;
	pinctrl-names = "default", "sleep";
};

&spi0 {
	compatible = "nordic,nrf-spi";
	/* Cannot be used together with i2c0. */
	/* status = "okay"; */
	pinctrl-0 = <&spi0_default>;
	pinctrl-1 = <&spi0_sleep>;
	pinctrl-names = "default", "sleep";
};

&spi1 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	pinctrl-0 = <&spi1_default>;
	pinctrl-1 = <&spi1_sleep>;
	pinctrl-names = "default", "sleep";
};

arduino_spi: &spi3 {
	status = "okay";
	cs-gpios = <&arduino_header 16 GPIO_ACTIVE_LOW>; /* D10 */
	pinctrl-0 = <&spi3_default>;
	pinctrl-1 = <&spi3_sleep>;
	pinctrl-names = "default", "sleep";
};

&ieee802154 {
	status = "okay";
};

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0xC000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x37000>;
		};
		slot1_partition: partition@43000 {
			label = "image-1";
			reg = <0x00043000 0x37000>;
		};
		storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007A000 0x00006000>;
		};
	};
};

zephyr_udc0: &usbd {
	compatible = "nordic,nrf-usbd";
	status = "okay";
};

/*
 * Copyright (c) 2022 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: Apache-2.0
 */

&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>;
	/* This is a setting that enables antenna 12 (in antenna matrix designed
	 * by Nordic) for Rx 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 when AoA is enabled.
	 * Pin numbers are selected to drive switches on antenna matrix
	 * designed by Nordic. For more information see README.rst.
	 */
	dfegpio0-gpios = <&gpio0 3 0>;
	dfegpio1-gpios = <&gpio0 4 0>;
	dfegpio2-gpios = <&gpio0 28 0>;
	dfegpio3-gpios = <&gpio0 29 0>;
};

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Tue, 02 Apr 2024 13:42:52 GMT

Yes, I built the default Direction_finding_central without anything modified and then I got this error. My target board is nRF52833DK with an antenna array designed by Nordic.

Regards,

Zihao

RE: Problems building Direction_finding_central sample

Elfving — Tue, 02 Apr 2024 13:03:22 GMT

I am sorry to hear that.

[quote user="Zihao"]Hi, the connectionless sample is working well but doesn't meet my requirement [sad]. Thank you for your reply[/quote]

Im still adamant about the connected sample working though, if you want to discuss that further.

Regards,

Elfving

RE: Problems building Direction_finding_central sample

Zihao — Tue, 02 Apr 2024 12:51:20 GMT

Hi, the connectionless sample is working well but doesn't meet my requirement [sad]. Thank you for your reply.

RE: Problems building Direction_finding_central sample

Elfving — Tue, 02 Apr 2024 12:21:07 GMT

Hello Yang,

So this is the default sample, without anything modified? What board are you building it for?

Regards,

Elfving

RE: Problems building Direction_finding_central sample

johan_1234 — Tue, 02 Apr 2024 08:49:02 GMT

Hi, not really. Because I am more interested in getting IQ measurements with an antenna array, I switched to the connectionless sample and its what I am using now.

RE: Problems building Direction_finding_central sample

Zihao — Mon, 01 Apr 2024 08:13:47 GMT

Hello, I have the same problem as you. And have you solved it?

RE: Problems building Direction_finding_central sample

Zihao — Mon, 01 Apr 2024 08:12:41 GMT

Hello,

I am encountering the same issue. The problem appears to be related to the build process rather than hardware, as it occurred during building and resulted in failure. Specifically, when using nRF Connect SDK for VSCode (version v2.5.1), I encountered the error while building the existing Sample (Direction finding central) without flashing the program to any hardware.

Furthermore, my environment configuration seems to be correct as I can run all the demos in Bluetooth Low Energy Fundamentals without any issues. Are there any additional docs or solutions available that could help me?

RE: Problems building Direction_finding_central sample

PaKa — Wed, 21 Feb 2024 14:52:54 GMT

Start with a sample from the nRF folder, these are what we build and test against.

RE: Problems building Direction_finding_central sample

johan_1234 — Wed, 21 Feb 2024 14:51:06 GMT

I am using the Zephyr controller as far as I know. I tried building the sample using the toolchain and SDK v2.1.0 but run into the same issue.

What I need is to receive I/Q samples using AoA mode. Is there maybe a better sample to get this?

C:\ncs\zephyr\samples\bluetooth\direction_finding_central>west build -b nrf52833dk_nrf52833 -- -DCONF_FILE=prj.conf
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: C:/ncs/zephyr/samples/bluetooth/direction_finding_central
-- Using NCS Toolchain 2.1.0 for building. (C:/ncs/toolchains/v2.1.0/cmake)
-- Found Python3: C:/ncs/toolchains/v2.1.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/zephyr/.cache
-- Zephyr version: 3.1.99 (C:/ncs/zephyr)
-- Found west (found suitable version "0.14.0", minimum required is "0.7.1")
-- Board: nrf52833dk_nrf52833
-- Found host-tools: zephyr 0.14.1 (C:/ncs/toolchains/v2.1.0/opt/zephyr-sdk)
-- Found dtc: C:/ncs/toolchains/v2.1.0/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: zephyr 0.14.1 (C:/ncs/toolchains/v2.1.0/opt/zephyr-sdk)
-- Found BOARD.dts: C:/ncs/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts
-- Found devicetree overlay: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/boards/nrf52833dk_nrf52833.overlay
-- Generated zephyr.dts: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/dts.cmake

warning: BT_DF (defined at C:/ncs/zephyr/subsys/bluetooth/host/Kconfig:636,
subsys/bluetooth\host/Kconfig:636) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: (((!BT_CTLR || BT_CTLR_DF_SUPPORT) && BT_HCI_HOST && BT_RPC_STACK) ||
((!BT_CTLR || BT_CTLR_DF_SUPPORT) && BT_HCI_HOST && BT_HCI && BT)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_DF and/or look up BT_DF in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.


warning: BT_DF_CONNECTION_CTE_RX (defined at C:/ncs/zephyr/subsys/bluetooth/host/Kconfig:661,
subsys/bluetooth\host/Kconfig:661) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: (((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST &&
BT_RPC_STACK) || ((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST && BT_HCI && BT))
(=nParsing C:/ncs/zephyr/samples/bluetooth/direction_finding_central/Kconfig
Loaded configuration 'C:/ncs/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833_defconfig'
Merged configuration 'C:/ncs/zephyr/samples/bluetooth/direction_finding_central/prj.conf'
Configuration saved to 'C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/.config'
Kconfig header saved to 'C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/include/generated/autoconf.h'
). See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_DF_CONNECTION_CTE_RX and/or
look up BT_DF_CONNECTION_CTE_RX in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.


warning: BT_DF_CONNECTION_CTE_REQ (defined at C:/ncs/zephyr/subsys/bluetooth/host/Kconfig:675,
subsys/bluetooth\host/Kconfig:675) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: ((BT_DF_CONNECTION_CTE_RX && BT_DF && BT_HCI_HOST && BT_RPC_STACK) ||
(BT_DF_CONNECTION_CTE_RX && BT_DF && BT_HCI_HOST && BT_HCI && BT)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_DF_CONNECTION_CTE_REQ and/or look up
BT_DF_CONNECTION_CTE_REQ in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Configuring done (17.3s)
-- Generating done (0.3s)
-- Build files have been written to: C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build
←[92m-- west build: building application
[1/220] Generating include/generated/version.h
-- Zephyr version: 3.1.99 (C:/ncs/zephyr), build: v3.1.99-ncs1
[51/220] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj
C:\ncs\toolchains\v2.1.0\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DKERNEL -DNRF52833_XXAA -DUSE_PARTITION_MANAGER=0 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/ncs/nrf/drivers/mpsl/clock_control -IC:/ncs/zephyr/include/zephyr -IC:/ncs/zephyr/include -IC:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/include/generated -IC:/ncs/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/ncs/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/zephyr/subsys/bluetooth -IC:/ncs/nrf/include -IC:/ncs/nrf/lib/multithreading_lock/. -IC:/ncs/nrf/subsys/bluetooth/controller/. -IC:/ncs/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/modules/hal/nordic/nrfx -IC:/ncs/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/modules/hal/nordic/nrfx/mdk -IC:/ncs/zephyr/modules/hal_nordic/nrfx/. -IC:/ncs/modules/debug/segger/SEGGER -IC:/ncs/modules/debug/segger/Config -IC:/ncs/zephyr/modules/segger/. -IC:/ncs/modules/crypto/tinycrypt/lib/include -IC:/ncs/nrfxlib/mpsl/include -IC:/ncs/nrfxlib/mpsl/include/protocol -IC:/ncs/nrfxlib/softdevice_controller/include -isystem C:/ncs/zephyr/lib/libc/minimal/include -isystem c:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/include -isystem c:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/include-fixed -Os -imacros C:/ncs/zephyr/samples/bluetooth/direction_finding_central/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfp16-format=ieee --sysroot=C:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/ncs/zephyr/samples/bluetooth/direction_finding_central=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF CMakeFiles\app.dir\src\main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj -c C:/ncs/zephyr/samples/bluetooth/direction_finding_central/src/main.c
C:/ncs/zephyr/samples/bluetooth/direction_finding_central/src/main.c:283:3: error: 'const struct bt_conn_cb' has no member named 'cte_report_cb'
  283 |  .cte_report_cb = cte_recv_cb,
      |   ^~~~~~~~~~~~~
C:/ncs/zephyr/samples/bluetooth/direction_finding_central/src/main.c:283:19: warning: initialization of '_Bool (*)(struct bt_conn *, struct bt_le_conn_param *)' from incompatible pointer type 'void (*)(struct bt_conn *, const struct bt_df_conn_iq_samples_report *)' [-Wincompatible-pointer-types]
  283 |  .cte_report_cb = cte_recv_cb,
      |                   ^~~~~~~~~~~
C:/ncs/zephyr/samples/bluetooth/direction_finding_central/src/main.c:283:19: note: (near initialization for 'bt_conn_cb_conn_callbacks.le_param_req')
[64/220] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/fdtable.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\ncs\zephyr\samples\bluetooth\direction_finding_central\build'

RE: Problems building Direction_finding_central sample

PaKa — Tue, 20 Feb 2024 15:14:49 GMT

Is this by any chance trying to use the SoftDevice Controller? This doesn't support reception of CTE. If you need to receive CTE and you want to qualify the product then you should use nRF Connect SDK 2.1.0 as that is the only one with a valid QDID for the receiver side, and you must use the Zephyr controller.