• State Verified Answer
  • Replies 9 replies
  • Subscribers 76 subscribers
  • Views 468 views
  • Users 0 members are here
Attachments (6) Download All
Nordic Case Info
  • Case ID: 339799
Options

HCI Number of Completed Packet Event missing for ISO packets on CIG with 2 CIS on nRF5340

Matthias Ringwald

Hi there

I'm using a nRF5340 (DK or ADK) with the Zephyr HCI UART sample from NCS v2.9 and the SoftDevice to stream music to two headsets (1 CIG with two CIS) from our stack running on a desktop.

After sending a few packets, the SoftDevice Controller does not emit a HCI Number of Completed Packets for one of the CIS handles, in the attached logs rather consistent for the 5th packet - please see logs. (There's also Connection timeout later in one or two logs, which is caused by the current PTS dongle firmware on the remote side and which is not relevant here). I'd expect to always get a HCI Number of Completed Packets event even if there are transmission problems. (I'd 

When testing with NCS 2.9 on the nRF54L15, this does not seem to happen on a first glance.

Is this a bug in the SoftDevice implementation for the nRF5340? Is there anything I should change?

Thanks for looking into this,

gateway-nrf5340-dk-ncs-2.9-2.pklggateway-nrf5340-dk-ncs-2.9-1.pklggateway-nrf5340-adk-ncs-2.9-2.pklggateway-nrf5340-adk-ncs-2.9-1.pklg Matthias

Parents
  • 0

    Hi,

    Could you point us to which of the log files which are relevant and which packet number corresponds to "the 5th packet"? 

     

    In which type of application do you need to open these logs? When opening them in Wireshark I cannot see any ISO packet, but there are many lines similar to

     "1176  33.121351      PKTLOG      Unknown 0x0c      ". 

    I'm wondering if this is ISO packets or something else

    -Amanda H.

  • 0 in reply to Amanda Hsieh

    Thanks for looking into this.

    The log files can be opened on macOS with PacketLogger. Wireshark can read this format as well, but ISO packets are not decoded/parsed. Sorry for the inconvenience.

    I've rerun the test and logged into BTsnoop packet format, which displays correctly in Wireshark (4.4.3).

    In the file ....3.btsnoop, there's no event for packet 746, in file ....4.btsnoop, there's no event for packet 868.

    Thanks, Matthias

    gateway-nrf5340-dk-ncs-2.9.zip

  • 0 in reply to Matthias Ringwald

    Could you also provide the .config files under build/app_name/zephyr?

    Have you 

    • logging enabled on both cores / checked the logs for errors
    • checked if the SDUs he sent to the controller are sent out (received by the peer device / visible on air with a sniffer)

    ?

  • 0 in reply to Amanda Hsieh

    Sure. The attached conffigs.zip contains the .config for both hci_uart and ipc_uart.

    I didn't have logging enabled (I'm happy enough to be able to compile and flash it). I've added  -DEXTRA_CONF_FILE='debug.conf' and used Ozone with the .elf file for the App Core and got RTT debug output. It shows the Zephyr boot banner and occasionally an overview over thread and their stack usage. They are no messages related to Bluetooth errors.

    I've tried to use Ozone with the .elf for ipc_radio which seems to work, but there is no RTT debug output. How can I enable logging in the hci_uart example for nRF5340 of the NetCore?

    The missing SDU is not received on the peer device and we don't have a LE Audio-able sniffer. 

    ---

    As hci_uart is only forwarding packets to the NetCore and there are no errors while the second connection stays stable, it seems that the SoftDevice implementation discards an ISO packet without emitting an HCI Number of Completed Packets.

    Is this a reasonable observation?

    Is there a path in the SoftDevice where this would happen (under whatever conditions) ?

    In a quick test, this does not seem to happen on the nRF54L15. I get LMP Subversion 0x206b on the nRF5340 and 0x306b on the nRF54L15.

    Are these the same SoftDevice version, resp. does the LMP Subversion indicate the SoftDevice version?

    Thanks,

     Matthias

    8372.configs.zip

  • +1 in reply to Matthias Ringwald

    Hi, 

    Matthias Ringwald said:
    I've tried to use Ozone with the .elf for ipc_radio which seems to work, but there is no RTT debug output. How can I enable logging in the hci_uart example for nRF5340 of the NetCore?

    I think one of the places where the SDU could get lost is https://github.com/nrfconnect/sdk-zephyr/blob/main/samples/bluetooth/hci_ipc/src/main.c#L143 so enabling logging on the network core is probably the key here. 

    If that is the case, then increasing the CONFIG_BT_ISO_TX_BUF_COUNT on the network core should resolve the issue.

    Setting this to the same value as CONFIG_BT_CTLR_SDC_ISO_TX_HCI_BUFFER_COUNT is probably a good idea.

    -Amanda H.

Reply Children
Related
Terms of service