Flashing Direction Finding Connectionless rx sample to nRF5340 -> GPIO toggling for antennae switching not working

Hi,

I am working on a AoA project and I am using modified main.c script form direction_finding_connectionless_rx sample. My program was working fine with nRF52833 DK but then I decided to switch to nRF5340 for more processing power. Now I want to have BLE controller on network core and host and application on application core. I followed guides on https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf5340.html and webinar https://www.youtube.com/watch?v=uqKxmsrP2Hc. Additionally I am using Boostxl-AoA antenna array from Texas Instruments.

With new board (nRF5340 DK) toggling GPIO pins for antenna switching is not working. There is no toggling of any pin (0V all the time). Everything else works as expected (receiver is able to receive periodic advertising packets with CTE and I get the IQ data).

So my procedure for flashing is like this:

1. I modified hci_rmpsg sample from Zephyr repo so it included boards directory with nrf5340dk_nrf5340_cpunet.conf file:

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

CONFIG_BT_CTLR=y
CONFIG_BT_LL_SW_SPLIT=y

CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_SYNC_PERIODIC=y

# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_CTLR_DF=y

# Disable Direction Finding TX mode
CONFIG_BT_CTLR_DF_ANT_SWITCH_TX=n
CONFIG_BT_CTLR_DF_ADV_CTE_TX=n

CONFIG_BT_EXT_ADV=y

and nrf5340dk_nrf5340_cpunet.overlay file:

/*
 * Copyright (c) 2021 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

&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 = <16>;
	/* 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 = <0x5>;

	/* 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
	 * 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>; 
};

I also modified prj.conf to look like this:

CONFIG_RPMSG_SERVICE=y
CONFIG_RPMSG_SERVICE_MODE_REMOTE=y

CONFIG_HEAP_MEM_POOL_SIZE=8192

CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_CTLR_ASSERT_HANDLER=y
CONFIG_BT_HCI_RAW_RESERVE=1
CONFIG_BT_BUF_CMD_TX_COUNT=4


# Required to enable BT_BUF_CMD_TX_SIZE for LE Set Extended Advertising Data command
CONFIG_BT_EXT_ADV=y

# Required to enable BT_PER_ADV_SYNC_MAX
CONFIG_BT_PER_ADV_SYNC=y
CONFIG_BT_OBSERVER=y

#CONFIG_BT_CTLR=y
CONFIG_BT_LL_SW_SPLIT=y

#CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_SYNC_PERIODIC=y

# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_CTLR_DF=y
CONFIG_BT_CTLR_DF_ANT_SWITCH_TX=n

# Disable Direction Finding TX mode
CONFIG_BT_CTLR_DF_ADV_CTE_TX=n

# Disable AoA Feature (antenna switching) in Rx mode
CONFIG_BT_CTLR_DF_ANT_SWITCH_RX=y

2. I build and flash hci_rpmsg sample with:

west build -b  nrf5340dk_nrf5340_cpunet

west flash

3. I copied Bluetooth: Direction finding connectionless locator sample from nRF Connect SDK in separate directory. I modified main.c according to my application. My prj.conf file looks like this:

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

#CONFIG_BT_RPMSG_NRF53=y
CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="Locator nRF5340 DK"

CONFIG_BT_EXT_ADV=y
CONFIG_BT_PER_ADV_SYNC=y
CONFIG_BT_OBSERVER=y

# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_DF=y
CONFIG_BT_DF_CONNECTIONLESS_CTE_RX=y


CONFIG_FPU=y
# for inlcude <math.h>	
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_NANO=y

CONFIG_MAIN_STACK_SIZE=8192

And my overlay-aod.conf file like this:

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

# Disable AoA Feature (antenna switching) in Rx mode
CONFIG_BT_CTLR_DF_ANT_SWITCH_RX=n

4. I build and flash application to application core:

west build -b nrf5340dk_nrf5340_cpuapp

west flash

Application is working as expected. I am even getting CTE packets but with very low amplitude of IQ samples. From that hit I suspected that no antenna was selected. With oscilloscope I checked GPIO levels (p0.04, p0.05, p0.06, p0.07 -> as default configuration) that are responsible for switching antennae and for sure they are all 0V all the time. My design must have at least one pin always "one"  so that one of antennae is selected. So no antenna is selected. I guess my board can still receive periodic advertising packets with no antennae selected but the amplitude is very small. When i disconnect my antenna array form DK (I am using Murata  MXHS83QE3000 test probe to connect antenna array) and receive with just PCB antenna, then amplitudes of IQ samples get much bigger and I get no toggling of GIPO pins anyway.

Does anyone have any idea why GPIO pins are not toggling?

I tried with different GPIO pins (p1.09, p1.08, p1.05, p1.04) and got the same result.

I tried building and flashing both cores as described in Working with nRF5340. So I added child_image to root directory of application directory. But when I build the app I did not get any additional directory build/\hci_rpmsg as described here: https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/getting-started/posts/nrf-connect-sdk-tutorial---part-1-ncs-v1-4-0. So I stayed at flashing cores separately as described above.

Can GPIOs be controlled by network core? Is there a secure/unsecure relation broken?

Did I wrongly configured my prj.conf files and when flashing application image, network image is somehow overridden?

I am stuck and I do not know what else to do. Any help would be appreciated.

Thanks

Parents
  • Hi

    What version of the nRFConnect SDK (NCS) are you using for your project? Earlier versions of the locator sample has had some trouble on the nRF5340, so I would recommend using NCS v1.8.0. Have you checked out the direction finding RX example's GitHub which has more information on how to run the application on an nRF5340 DK. If you're using Angle of Arrival (the central as the locator device with antenna array), you don't need the aod.conf overlay file as this is only used for the AoD mode.

    Please make sure that these GPIOs aren't conflicting with some other peripherals, as I think P0.05-P0.07 for example are used by the UART for logging by default, but it seems strange that none of the GPIOs you mention are toggling. 

    Best regards,

    Simon

  • Hi, thanks for the reply.

    Actually I build this application with Zephyr SDK of version 2.6. (they released sample application prior to NCS as I know so I went with Zephyr direction_finding_connectionless_rx sample)

    I have checked out the Github example you have provided and modifed hci_rpmsg example as described.

    Please make sure that these GPIOs aren't conflicting with some other peripherals, as I think P0.05-P0.07 for example are used by the UART for logging by default,

    I looked in https://infocenter.nordicsemi.com/pdf/nRF5340_DK_User_Guide_20210304.pdf DK user guide and I did not found any conflicting peripherals for these GPIOs (expect that they can be used as Analog input). I checked nRF5340 PS too. That is why I stayed at these GPIOs because they are listed as default for sample application.

    After I wrote the post I downloaded newest version of NCS verison 1.8.99. Main idea was to build sample application direction_finding_connectionless_rx form scratch. I have followed instructions for multi image build and quickly ran into problem. SRAM size for network core was too small (linker error). I figured out that if I decrease CONFIG_BT_MAX_CONN from 16 to for example 2  for hci_rpmsg sample, than this error is fixed. Sample is then build nicely for both images (child and parent image). But when I run the application on DK, it keeps rebooting after it gets to the point "Waiting for periodic sync...".  I managed to get some info about it from btmon --tty /dev/ttyACM2 --tty-speed 115200. Here is the last relevant section from output:

    = bt: bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)          0.376000
    = bt: bt_hci_core: HW Variant: nRF53x (0x0003)                         0.376000
    = bt: bt_hci_core: Firmware: Standard Bluetooth controller (0x00)...   0.376000
    = bt: bt_hci_core: Identity: FD:4B:39:E2:9B:77 (random)                0.401800
    = bt: bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufa..   0.401800
    = bt: bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff               0.401800
    = bt: os: ***** USAGE FAULT *****                                      0.621600
    = bt: os:   Stack overflow (context area not valid)                    0.621600
    = bt: os: r0/a1:  0x200010d8  r1/a2:  0x20002560  r2/a3:  0x20005190   0.621600
    = bt: os: r3/a4:  0x000004e9 r12/ip:  0x00000000 r14/lr:  0x00004ee5   0.621600
    = bt: os:  xpsr:  0x21000200                                           0.621600
    = bt: os: Faulting instruction address (r15/pc): 0x000004f0            0.621600
    = bt: os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0            0.621600
    = bt: os: Current thread: 0x20000578 (unknown)                         0.621700
    = bt: fatal_error: Resetting system                                   0.712800
    Received corrupted data from TTY
    Received corrupted data from TTY
    

    With tool addr2line I found that faulty instruction (Faulting instruction address (r15/pc): 0x000004f0) correspond to line 122 in main.c which is begging of function: static void recv_cb(struct bt_le_per_adv_sync *sync, const struct bt_le_per_adv_sync_recv_info *info, struct net_buf_simple *buf). I tried increasing stack size of main.c of both sample application direction_finding_connectionless_rx and hci_rpmsg sample with CONFIG_MAIN_STACK_SIZE. I also tried with increasing CONFIG_BT_RX_STACK_SIZE. Both options did not fix the problem.

    Then I downloaded newest version of Zephy SDK project. Main idea was to build their direction_findinf_connectionless_rx application in combination with their hci_rpmsg sample. I needed to decrease CONFIG_BT_MAX_CONN to not get SRAM overflow when building as described above. I managed to receive IQ samples from CTE but RSSI value was around -80 to -90 indicating that no antenna was selected which indicated GPIO toggling did not work (I probed GPIOs to confirm that).

    Then I tried various combinations:

    - Zephy SDK sample application with NCS hci_rpmsg sample

    -changing BLE controller between soft device and zephyr controller.

    Nothing worked (application signaled error when some configurations were applied or the application just stopped at "CTE receive enabled").

    Can you try the sample application for nRF5340 DK (either with NCS or Zephyr project SDK) and see if you get any of these problems and if GPIO toggling is working?

    Thanks in advence,

    Aleš

Reply
  • Hi, thanks for the reply.

    Actually I build this application with Zephyr SDK of version 2.6. (they released sample application prior to NCS as I know so I went with Zephyr direction_finding_connectionless_rx sample)

    I have checked out the Github example you have provided and modifed hci_rpmsg example as described.

    Please make sure that these GPIOs aren't conflicting with some other peripherals, as I think P0.05-P0.07 for example are used by the UART for logging by default,

    I looked in https://infocenter.nordicsemi.com/pdf/nRF5340_DK_User_Guide_20210304.pdf DK user guide and I did not found any conflicting peripherals for these GPIOs (expect that they can be used as Analog input). I checked nRF5340 PS too. That is why I stayed at these GPIOs because they are listed as default for sample application.

    After I wrote the post I downloaded newest version of NCS verison 1.8.99. Main idea was to build sample application direction_finding_connectionless_rx form scratch. I have followed instructions for multi image build and quickly ran into problem. SRAM size for network core was too small (linker error). I figured out that if I decrease CONFIG_BT_MAX_CONN from 16 to for example 2  for hci_rpmsg sample, than this error is fixed. Sample is then build nicely for both images (child and parent image). But when I run the application on DK, it keeps rebooting after it gets to the point "Waiting for periodic sync...".  I managed to get some info about it from btmon --tty /dev/ttyACM2 --tty-speed 115200. Here is the last relevant section from output:

    = bt: bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)          0.376000
    = bt: bt_hci_core: HW Variant: nRF53x (0x0003)                         0.376000
    = bt: bt_hci_core: Firmware: Standard Bluetooth controller (0x00)...   0.376000
    = bt: bt_hci_core: Identity: FD:4B:39:E2:9B:77 (random)                0.401800
    = bt: bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufa..   0.401800
    = bt: bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff               0.401800
    = bt: os: ***** USAGE FAULT *****                                      0.621600
    = bt: os:   Stack overflow (context area not valid)                    0.621600
    = bt: os: r0/a1:  0x200010d8  r1/a2:  0x20002560  r2/a3:  0x20005190   0.621600
    = bt: os: r3/a4:  0x000004e9 r12/ip:  0x00000000 r14/lr:  0x00004ee5   0.621600
    = bt: os:  xpsr:  0x21000200                                           0.621600
    = bt: os: Faulting instruction address (r15/pc): 0x000004f0            0.621600
    = bt: os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0            0.621600
    = bt: os: Current thread: 0x20000578 (unknown)                         0.621700
    = bt: fatal_error: Resetting system                                   0.712800
    Received corrupted data from TTY
    Received corrupted data from TTY
    

    With tool addr2line I found that faulty instruction (Faulting instruction address (r15/pc): 0x000004f0) correspond to line 122 in main.c which is begging of function: static void recv_cb(struct bt_le_per_adv_sync *sync, const struct bt_le_per_adv_sync_recv_info *info, struct net_buf_simple *buf). I tried increasing stack size of main.c of both sample application direction_finding_connectionless_rx and hci_rpmsg sample with CONFIG_MAIN_STACK_SIZE. I also tried with increasing CONFIG_BT_RX_STACK_SIZE. Both options did not fix the problem.

    Then I downloaded newest version of Zephy SDK project. Main idea was to build their direction_findinf_connectionless_rx application in combination with their hci_rpmsg sample. I needed to decrease CONFIG_BT_MAX_CONN to not get SRAM overflow when building as described above. I managed to receive IQ samples from CTE but RSSI value was around -80 to -90 indicating that no antenna was selected which indicated GPIO toggling did not work (I probed GPIOs to confirm that).

    Then I tried various combinations:

    - Zephy SDK sample application with NCS hci_rpmsg sample

    -changing BLE controller between soft device and zephyr controller.

    Nothing worked (application signaled error when some configurations were applied or the application just stopped at "CTE receive enabled").

    Can you try the sample application for nRF5340 DK (either with NCS or Zephyr project SDK) and see if you get any of these problems and if GPIO toggling is working?

    Thanks in advence,

    Aleš

Children
No Data
Related