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

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

  • Hi again

    We've had a few cases with issues regarding the direction finding sample on the nRF5340 DK already, and this case specifically has some great pointers that have helped a few DevZone users getting the example up and running on an nRF5340 DK already, so please check it out.

    Best regards,

    Simon

  • Hi, thanks for reply. I followed your suggestion but could not fix the issue.

    I documented everything I tried if anyone wants to recreate my problem or if anyone finds it useful for future debugging. Below is written documentation step by step. Anyway I could not find a solution so I am a little disappointed by choosing nRF5340.

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

    NEW NCS INSTALL (building application with NCS):
    I installed NCS in selected directory with:
    "west init -m github.com/.../sdk-nrf --mr main"
    "west update"
    Since I installed NCS before I did not needed to install other dependencies.

    I went to nrf/samples/bluetooth/direction_finding_connectionless_rx direcotry. I followed instructions to build this application for AoA mode on developer.nordicsemi.com/.../README.html
    I copied content of overlay-aod.conf to child_image/hci_rpmsg.conf
    I built application with "west build -b nrf5340dk_nrf5340_cpuapp"
    Build resulted in build linker error: `noinit' will not fit in region `SRAM'

    To fix above problem I added line to child_image/hci_rpmsg.conf:
    CONFIG_BT_MAX_CONN=2
    Again building the appliaction: build completed without errors.
    I started: "minicom -D /dev/ttyACM2 -b 115200" to see log of application.
    I saw that DK is resetting every time after it logged "Waiting for periodic sync..."

    Next I tried changing  CONFIG_BT_CTLR_DF_ANT_SWITCH_RX=n (copied from overlay-aod.conf as explained in readme of application) to =y since this option is much more logical to me to use for AoA.
    I built the application resulting in error: "Missing antenna pattern used to select antenna for PDU Tx during the DFE Idle state. Set the dfe-pdu-antenna devicetree property."
       88 | BUILD_ASSERT(HAS_PDU_ANTENNA,   AND some more related errors to devicetree missing options
       
    I noticed that child_image/hci_rpmsg/nrf5340dk_nrf5340_cpunet.overlay was not found by build process so I added it to zephyr/samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340_cpunet.overlay.
    In board overlay file I changed some properties according to my design:
         "dfe-pdu-antenna = <0x5>;
        dfegpio0-gpios = <&gpio1 9 0>;
        dfegpio1-gpios = <&gpio1 8 0>;
        dfegpio2-gpios = <&gpio1 5 0>;
        dfegpio3-gpios = <&gpio1 4 0>;"

    I again built the application without errors. But when I flashed application it kept resetting at the same time as explained above.

    Then I went to look all Kconfig options for direction finding at developer.nordicsemi.com/.../index-all.html.
    In child_image/hci_rpmsg.conf I added all option that I think are relevant to AoA application:
    CONFIG_BT_CTLR_DF=y
    CONFIG_BT_CTLR_DF_CTE_RX=y
    CONFIG_BT_CTLR_DF_SCAN_CTE_RX=y
    CONFIG_BT_CTLR_DF_CTE_RX_SAMPLE_1US=y
    CONFIG_BT_CTLR_DF_ANT_SWITCH_RX=y
    CONFIG_BT_CTLR_DF_DEBUG_ENABLE=y
    CONFIG_BT_CTLR_DF_INIT_ANT_SEL_GPIOS=y

    And... application kept resetting at "Waiting for periodic sync..."

    I tried different GPIO configuration:
        "dfegpio0-gpios = <&gpio0 4 0>;
        dfegpio1-gpios = <&gpio0 5 0>;
        dfegpio2-gpios = <&gpio0 6 0>;
        dfegpio3-gpios = <&gpio0 7 0>;"


    And got same result..

    Then I tried incresing some stacks of zephyr/samples/bluetooth/hci_rpmsg sample so I added these lines to nrf/samples/bluetooth/direction_finding_connectionless_rx/child_image/hci_rpmsg.conf
    "CONFIG_HEAP_MEM_POOL_SIZE=8192
    CONFIG_MAIN_STACK_SIZE=2048
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
    CONFIG_BT=y
    CONFIG_BT_HCI_RAW=y
    CONFIG_BT_MAX_CONN=1
    CONFIG_BT_CTLR_ASSERT_HANDLER=y
    CONFIG_BT_HCI_RAW_RESERVE=1
    CONFIG_BT_BUF_CMD_TX_COUNT=4
    CONFIG_BT_RX_STACK_SIZE=2048"

    And.. got same result.

    Lastly I tried by setting:
    CONFIG_BT_LL_SOFTDEVICE=y in /child_image/hci_rpmsg.conf
    This time  I managed to get to:
    Enable receiving of CTE...
    failed (err -134)
    In addition SRAM used size when building application for network core was notably smaller and I did not have to include CONFIG_BT_MAX_CONN and kept it as default (16)
    During build I also got warnings:
    warning: BT_CTLR_DF (defined at subsys/bluetooth/controller/Kconfig.df:32) was assigned the value
    'y' but got the value 'n'. Check these unsatisfied dependencies: BT_CTLR_DF_SUPPORT (=n). See
    docs.zephyrproject.org/.../CONFIG_BT_CTLR_DF.html and/or look up
    BT_CTLR_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_CTLR_DF_ANT_SWITCH_RX (defined at subsys/bluetooth/controller/Kconfig.df:81) was
    assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
    BT_CTLR_DF_CTE_RX (=n), BT_CTLR_DF_ANT_SWITCH_2US_SUPPORT (=n), BT_CTLR_DF (=n). See
    docs.zephyrproject.org/.../CONFIG_BT_CTLR_DF_ANT_SWITCH_RX.html and/or
    look up BT_CTLR_DF_ANT_SWITCH_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.

    After looking for possible solutions and not finding solution I decided so I throw away that attempt.

    Every time I built application I prior to that deleted build directory so previous builds could not interfere with current build.


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

    NEW ZEPHYR SKD INSTALL (building application with just Zephyr SDK):
    I installed latest Zephyr SDK with:
    west init
    west update

    I then followed instructions on docs.zephyrproject.org/.../README.html to build sample for nRF5340
         "- Copy samples/bluetooth/direction_finding_connectionless_rx/boards/nrf52833dk_nrf52833.overlay to a new file, samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340_cpunet.overlay.

        - Copy samples/bluetooth/direction_finding_connectionless_rx/boards/nrf52833dk_nrf52833.conf to a new file, samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340_cpunet.conf. Add the line CONFIG_BT_EXT_ADV=y to enable extended size of CONFIG_BT_BUF_CMD_TX_SIZE to support the LE Set Extended Advertising Data command"


    I built for network core in zephyr/samples/bluetooth/hci_rpmsg direcotry:
    west build -b  nrf5340dk_nrf5340_cpunet
    and got the following error: error: 'CONFIG_BT_PER_ADV_SYNC_MAX' undeclared here (not in a function)
       98 |         (CONFIG_BT_PER_ADV_SYNC_MAX) - 1),
          |          ^~~~~~~~~~~~~~~~~~~~~~~~~~

    I fixed the error by adding "CONFIG_BT_PER_ADV_SYNC=y" to zephyr/samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340_cpunet.conf

    Then next problem arised which was the same as with NCS: `noinit' will not fit in region `SRAM'
    I fixed it by adding "CONFIG_BT_MAX_CONN=1" zephyr/samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340_cpunet.conf

    Application was then build without errors.
    I flashed network core with: west flash

    I built application core with running below command in zephyr/samples/bluetooth/direction_finding_connectionless_rx:
    west build -b nrf5340dk_nrf5340_cpuapp
    and flashed it with:
    west flash

    I managed to get into cte_recv_cb() function. Reporting for PER_ADV_SYNC seems correct but report for CTE is completely wrong (example below):
    "PER_ADV_SYNC[0]: [DEVICE]: 1D:4D:95:CF:F6:7F (random), tx_power 127, RSSI -80, CTE AOA, data length 5, data: 04ffffff06
    CTE[42]: samples count 0, cte type Unknown, slot durations: 0 [us], packet status CRC OK, RSSI 0
    CTE[214]: samples count 0, cte type Unknown, slot durations: 0 [us], packet status CRC OK, RSSI 0"

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

    Ales

  • Hi,

    Just a note on this problem,  which I run into as well.

    The fact that the zephyr/nrf uses a pdu-antenna in hci_rpmsg to activate the switching hardware, and not used in my case, you need to be aware that the first gpio in your list is stolen from your switch gpio vectors for the chip select.

    Shown below:

    &gpio_fwd {
        dfe-gpio-if {
            gpios = <&gpio0 25 0>,    /* pdu-antenna */
                <&gpio0 4 0>,
                <&gpio0 5 0>,
                <&gpio0 6 0>,
                <&gpio0 7 0>;
            };

    And its crucial to shift your switch pattern one bit left in order to have the correct pin output when
    switching.

    pattern1 = 0b00000001   will fail without the shift <<1 , not working
    pattern1' = 0b00000010  will is the correct value because its the 2nd gpio (in the example gpio0-4)

    I hope this will help others to make it work.

    Chris

    Update:
    hci_rpmsg, If the boards/nrf5340dk_nrf5340_cpunet.overlay dfe-pdu-antenna = <0x1> set to <0x0> there will be no more 
    signal generate, and if your switch pattern have bit0 alway 0, it will work without shift << 1 as mention above.

    Anyway, a bit trail & error.

Related