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

[Amanda Hsieh]

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.

[Matthias Ringwald]

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

[Amanda Hsieh]

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)

?

[Matthias Ringwald]

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

[Amanda Hsieh]

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.

[Matthias Ringwald]

Hi Amanda. Thanks for pointing to place where the ISO packet most likely gets dropped. I have set CONFIG_BT_ISO_TX_BUF_COUNT to the value of  CONFIG_BT_CTLR_SDC_ISO_TX_HCI_BUFFER_COUNT and the issue did not happen anymore in a few tests.

--

So, each ISO TX packet requires:

- one buffer in the HCI UART bridge

- one buffer in the IPC_Radio bridge

- one buffer in the SoftDevice itself.

It would be nice if a compile time check could verify that CONFIG_BT_ISO_TX_BUF_COUNT >= CONFIG_BT_CTLR_SDC_ISO_TX_HCI_BUFFER_COUNT for both Cores.

--

Could you still explain how to enable RTT logging for the NetCore? I've tried to the following to sysbuild/ipc_radio/prj.cnf

CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_RTT_MODE_DROP=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=4096
CONFIG_LOG_DEFAULT_LEVEL=3

[Amanda Hsieh]

Matthias Ringwald said:

Could you still explain how to enable RTT logging for the NetCore?

It also needs CONFIG_LOG=y. 

[Matthias Ringwald]

Thank you. That one was missing.