nRF5340dk CTE extension is present but data is missing

RE: nRF5340dk CTE extension is present but data is missing

user75734 — Mon, 16 May 2022 13:13:07 GMT

I had a second look at your initial ticket and see that your log states that the nRF Connect SDK version used is v1.7.0. I asked the developers, and unfortunately, assignment of GPIO for antenna switch control was not added until the most recent version, and will be added in v2.0.0 of the nRF Connect SDK. Sorry about the misunderstanding. So how it is supported in your version, is unfortunately as the locator in an AoD application or a transmitter in an AoA application where it won't need an antenna array.

Best regards,

Simon

RE: nRF5340dk CTE extension is present but data is missing

user115884 — Fri, 13 May 2022 10:02:48 GMT

Yes, I have done these and I have also tested the nrf examples where those child_image folders are all set and configured, the same thing happens.

The problem is with opcode 0x2053 (enable HCI RX) which when sent from the application core to the network core cointains 10 bytes. When the network core parses the command, it expects 8 bytes for the parameter size after the packet indicator and the header (appointed by the header -> param_length) but there are 6 bytes left. This triggers the check, which then causes the network core to never enable CTE RX and also never give the sync semaphore, resulting in timeout on the application core.

RE: nRF5340dk CTE extension is present but data is missing

user75734 — Thu, 12 May 2022 12:41:23 GMT

Okay, have you done the necessary configurations in order to make the direction finding applications run on an nRF5340 DK? As mentioned in both the TX and RX samples, for the nRF53 DK, the Bluetooth LE controller is part of a child image aimed to run on the network core. Configuration for the child image is stored in the child_image/ subdirectory.

Also, to build the connectionless TX for AoA (or RX for AoD) you need to add the content of the overlay-aoa.conf file to your child_image/hcirpmsg.conf file.

Best regards,

Simon

RE: nRF5340dk CTE extension is present but data is missing

user115884 — Wed, 11 May 2022 06:36:41 GMT

Hi,

It's the line 304 in the hci_core.c which calls for k_sem_take that sends the -11 (-EAGAIN) value:
err = k_sem_take(&sync_sem, HCI_CMD_TIMEOUT);

I have tried to track the issue a bit, so for what I have found is that the issue comes when the function bt_hci_cmd_send_sync is called with opcode 0x2053 which is the HCI operation code for enabling CTE RX.

I have tried to increase the HCI_CMD_TIMEOUT manually (built in value seems to be set at K_SECONDS(10)) but it seems that either the operation with opcode 0x2053 never completes or it is not properly increasing the sync_sem value upon completion.

EDIT:

I found something more, which hopefully helps to resolve the issue:

On the cpunet side the event shows in error log as "Command payload length is not correct", which is a result of line 67 in main.c of the sample hci_rpmsg application for the cpunet.

So what happens is that the cpuapp tries to send the HCI enable CTE RX command with opcode 0x2053, but either the payload it sends is faulty or the cpunet sample application cannot handle the command/payload correctly.

As a result, the sync_semaphore is never given and the k_sem_take call blocks until the timeout, but the cause for all exsist in somewhere between how the enable CTE RX command is sent by the cpuapp and how it is handled by the cpunet.

RE: nRF5340dk CTE extension is present but data is missing

user75734 — Tue, 10 May 2022 12:01:01 GMT

What function is it that returns the EAGAIN error exactly? This error generally points to that you either should try again or that there are no more processes/contexts, depending on the function returning this error. Doesn't seem to be in the hci_core.c since it fails with an assertion fail.

Best regards,

Simon