samples:bluetoooth:direction_finding_connectionless_rx antenna switching not working with nRF5340

Hi I am working on direction_finding_connectionless_rx sample application. I recently migrated from nRF52833 DK to nRF5340 DK. When I was working with nRF52833 everything worked as expected. But for nRF5340 I noticed that GPIOs for controlling antennas are not toggling. I am using latest version of Zephyr SDK 3.0.99.

Here are my steps for building and flashing network core and application core: After installing Zephyr SDK I followed instructions on https://docs.zephyrproject.org/latest/samples/bluetooth/direction_finding_connectionless_rx/README.html. This means I copied: _samples/bluetooth/direction_finding_connectionless_rx/boards/nrf52833dknrf52833.overlay to _samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340cpunet.overlay and _samples/bluetooth/direction_finding_connectionless_rx/boards/nrf52833dknrf52833.conf to _samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340cpunet.conf and added CONFIG_BT_EXT_ADV=y. I also changed GPIO values for antenna switching in _samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340cpunet.overlay to: dfe-antenna-num = <3>; dfe-pdu-antenna = <0x5>; dfegpio0-gpios = <&gpio0 4 0>; dfegpio1-gpios = <&gpio0 5 0>; dfegpio2-gpios = <&gpio0 6 0>; dfegpio3-gpios = <&gpio0 7 0>;

and modified array variable _const static uint8_t antpatterns[] in_zephyr/samples/bluetooth/direction_finding_connectionlessrx/src/main.c according to my design (const static uint8_t ant_patterns[]= { 5U, 3U, 5U, 9U};)

Then I built hci_rpmsg for network core in zephyr/samples/bluetooth/hci_rpmsg direcotry: west build -b nrf5340dk_nrf5340_cpunet

The result of building were errors in a sense: _error: 'CONFIG_BT_PER_ADV_SYNC_MAX' undeclared here (not in a function) 98 | (CONFIG_BT_PER_ADV_SYNCMAX) - 1), | ^~~~~~

To fix the error I added "CONFIG_BT_PER_ADV_SYNC=y" to _zephyr/samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340cpunet.conf.

After rebuilding new error appeared: noinit will not fit in region SRAM I fixed above error with adding "CONFIG_BT_MAX_CONN=1" to _zephyr/samples/bluetooth/hci_rpmsg/boards/nrf5340dk_nrf5340cpunet.conf.

Then network application built successfully so I flashed it with: west flash.

Next I built and flash application core with running below command in zephyr/samples/bluetooth/direction_finding_connectionless_rx: _west build -b nrf5340dk_nrf5340cpuapp west flash

After looking at suspiciously low RSSI levels that application was sending via serial, I hooked up oscilloscope to GPIO pins that are responsible for antenna switching and found out that GPIO pins are dead (no toggling).

It is strange to me that even unmodified sample application was not built without errors. Am I doing something wrong or is nRF5340 DK still not supported by this sample? Can anyone confirm that this sample is working for that development board? From history logs on github I saw that some fixes were applied regarding nRF5340 and GPIOs.

I was building sample application on Ubuntu 21.10 and gcc-arm-none-eabi-10.3-2021.10 Additionally I deleted build folder between unsuccessful builds so older builds did not interfere with new builds.

Hi @ales5!

There are couple of things. 1) Radio peripheral is connected with network core, hence it has not access to GPIOs until application core assigns them to network core. That is solved by this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43532. Unfortunately the PR was merged a day after you have created the issue. 2) The direction_fingind_connectionless_rx sample is executed on application core while BLE Controller is part of hci_rpmsg sample. Zephyr currentyl han't got support for multi image builds. The hci_rpmsg sample is a generic sample application to run the most common BLE Controller functionalities. Direction finding isn't enabled there by default, so you have to customize the sample as you already did.

You can switch to use NCS SDK direction finding samples: https://github.com/nrfconnect/sdk-nrf/tree/main/samples/bluetooth. There is a multi image build possibility and there is a configuration for nRF53 SOCs for app and net cores. Although, there isn't added support for GPIOs forwarding mentioned in point 1. I'll add it ASAP.

Can you try to build you code from Zephyr latest main branch and check if GPIOs still does not work?

Hi @ppryga! First thank you for the amazing contribution for this sample application.

I tried with latest Zephyr main branch. With oscilloscope I can confirm that GPIO toggling for antenna switching IS working.

ant_sw

However, now it seems that I am not getting into cte_recv_cb() function. Is link for calling this function from network core broken? Here is the serial log I get when I ran the sample application (after sync is established only sync_cb() in called and no cte_recv_cb() ):

_ Booting Zephyr OS build zephyr-v3.0.0-1214-g2ef47509c371 Starting Connectionless Locator Demo Bluetooth initialization...success Scan callbacks register...success. Periodic Advertising callbacks register...success. Start scanning...success Waiting for periodic advertising...[DEVICE]: 24:A0:48:08:C8:1E (random), AD evt type 5, Tx Pwr: 127, RSSI -63 DF Connectionless Beacon App C:0 S:0 D:0 SR:0 E:1 Prim: LE 1M, Secn: LE 2M, Interval: 0x0120 (360 ms8 success. Found periodic advertising. Creating Periodic Advertising Sync...success. Waiting for periodic sync... [DEVICE]: 2B:48:FF:4D:D7:21 (random), AD evt type 3, Tx Pwr: 127, RSSI -96 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random) synced, Interval 0x0120 (360 ms), PHY LE 2M PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -63, CTE AOA, data length 5, data: 04ffffff06 success. Periodic sync established. Enable receiving of CTE... success. CTE receive enabled. Scan disable...Success. Waiting for periodic sync lost... PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -63, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -68, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -66, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -75, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -66, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -69, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -67, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -65, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -66, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -68, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -66, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -79, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -74, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -68, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -70, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -67, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -73, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), tx_power 127, RSSI -68, CTE AOA, data length 5, data: 04ffffff06 PER_ADV_SYNC[0]: [DEVICE]: 24:A0:48:08:C8:1E (random), txpower 127, RSSI -72, CTE AOA, data length 5, data: 04ffffff06 ... and so on ...

When I try the version of Zephyr SDK that I had when I wrote the first issue, than cte_recv_cb() is called just fine.

So in the latest version I get GPIO toggling (indicating that I am receiving CTE) but cte_revb_vb() is not called. I tried changing some values for CTE receiving but the issue remained.

@ales5 thank for reporting it. I did a mistake when selected GPIOs for application core. There used for other peripherals. That prevented to print any logs over UART and probably interfered with rpmsg passing from net-core to app core.

There is a PR: https://github.com/zephyrproject-rtos/zephyr/pull/43904 that should fix that. Please take a look on that.

@ppryga sorry for bothering, but I do not think this will solve the issue for not getting into cte_recv_cb(), since new selected GPIOs are the same that I used (for nRF5340) (see first post). Anyway I tried selecting different GPIOs (P1.09, P1.08, P1.05, P1.04) which are just general purpose digital I/Os and came to the same conclusion that switching is working but I do not get into cte_recv_cb(). Is maybe new GPIOs forwarding to network core interfering with rpmsg?

@ales5 I was writing about GPIOs in this file: https://github.com/zephyrproject-rtos/zephyr/blob/47059a09458f7f90fe5b44210643bc18be62b849/samples/bluetooth/direction_finding_connectionless_rx/boards/nrf5340dk_nrf5340_cpuapp.overlay#L15-L18 These GPIOs have to be set to the same port and pins as those in nrf5340dk_nrf5340_cpunet.overlay.

GPIOs assignments in nrf5340dk_nrf5340_cpuapp.overlay were updated in a PR: #43904. That solved the problem with no outputs printed through UART.

@ppryga Sorry I was not clear enough. I changed GPIOs of the _zephyr/samples/bluetooth/direction_finding_connectionless_rx/boards/nrf5340dk_nrf5340cpuapp.overlay as you specified and made sure that are same as in nrf5340dk_nrf5340_cpunet.overlay for hci_rpmsg sample (same values as you specified too). I am getting log printed through UART just fine. Only problem is that I am not getting into cte_recv_cb() callback function even though antenna switching is happening and sync_cb() is called (CTE parameters for receiving were not modified).

zephyrproject-rtos / zephyr

samples:bluetoooth:direction_finding_connectionless_rx antenna switching not working with nRF5340 #43656