• State Not Answered
  • Replies 5 replies
  • Subscribers 26 subscribers
  • Views 217 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288774
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

nRF5340dk CTE extension is present but data is missing

user115884

Hi,

I have been evaluating the nRF5340dk for our application purposes and I am currently investigating on how the bluetooth directional finding works.

I happened to encounter an issue with the zephyr and nordic connectionless tx/rx examples, where the transmitter is clearly showing it wants to send AoA/AoD data in the CTE but then on the receiver, there is no data received. After receiving the 5 empty samples, the receiver encounters an error and restarts the program.This seems to be true for both, AoA and AoD modes, please see the program output below.

EDITS FOR TRACKING ISSUE PROGRESS:

- The error it throws is EAGAIN (11), however, that does not still explain why there is no data in the CTE packages?

- The function throwing the error on the cpuapp side is line 304 in hci_core.c: k_sem_take for opcode 0x2053 (HCI enable CTE RX), on cpunet this shows as <err> hci_rpmsg: Command payload length is not correct which is line 67 of main.c in the hci_rpmsg sample application

- The problem is the HCI CTE enable RX command (opcode 0x2053) which should contain 8 bytes in the payload but application core is only sending 6. (10 bytes total, first byte is packet indicator, the following three are header for which opcode is two bytes and the third is the length of parameter and then the rest are the parameter payload bytes).

*** Booting Zephyr OS build v2.7.99-ncs1-7-ga49c0691993c  ***
Starting Connectionless Locator Demo
Bluetooth initialization...success
Scan callbacks register...success.
Periodic Advertising callbacks register...success.
Start scanning...success
Waiting for periodic advertising...[DEVICE]: D5:5E:E4:F6:AB:44 (random), AD evt type 3, Tx Pwr: 127, RSSI -80  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 1F:C1:8F:39:98:A0 (random), AD evt type 5, Tx Pwr: 127, RSSI -76 Zephyr C:0 S:0 D:0 SR:0 E:1 Prim: LE 1M, Secn: LE 2M, Interval: 0x0780 (2400 ms), SID: 0
success. Found periodic advertising.
Creating Periodic Advertising Sync...success.
Waiting for periodic sync...
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random) synced, Interval 0x0780 (2400 ms), PHY LE 2M
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random), tx_power 127, RSSI -83, CTE AOD 2 [us], data length 0, data: 
success. Periodic sync established.
Enable receiving of CTE...
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random), tx_power 127, RSSI -83, CTE AOD 2 [us], data length 0, data: 
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random), tx_power 127, RSSI -74, CTE AOD 2 [us], data length 0, data: 
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random), tx_power 127, RSSI -81, CTE AOD 2 [us], data length 0, data: 
PER_ADV_SYNC[0]: [DEVICE]: 1F:C1:8F:39:98:A0 (random), tx_power 127, RSSI -74, CTE AOD 2 [us], data length 0, data: 
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:305
*** Booting Zephyr OS build v2.7.99-ncs1-7-ga49c0691993c  ***

Parents
  • 0

    Hi

    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

  • 0 in reply to user75734

    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.

Reply
  • 0 in reply to user75734

    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.

Children
No Data
Related
Terms of service