Data Length Extension & BT CTLR on NRF53

[HichMenta]

Hi all,

Background:
-NRF5340
-NRF SDK 1.9
-Zephyr 2.7.99

My objective is to send via Bluetooth data of 244 Bytes every 10 ms per notify.

For the tests, I use the dongle Nrf52840 and the application NRF BLE v3.0.0.

Starting from the Zephyr and NRF examples, I was able to send data of 244 bytes size by increasing the MTU. However, what I observe is that the sending time is 30ms, that is the time to execute the bt_gatt_notify function ( measured with an oscilloscope by turning on and off a led before and after the execution of the bt_gatt_notify).
I strongly doubt that this is due to the data length which remains blocked at 27 Bytes
When trying to change the data length from NRF BLE application from 27 -> 251 Bytes, the command executes correctly but the data length is locked at 27 Bytes.

Secondly, when I want to change the data length from the zephyr config, I add in the prj.conf :

CONFIG_BT_CTLR=y

When compiling the project, I get an error :
warning: ENTROPY_NRF5_RNG (defined at c:\Users\hiche\workspace\M01-NRF\build\drivers\entropy\Kconfig.nrf5:14) has direct dependencies !ENTROPY_NRF_FORCE_ALT && HAS_HW_NRF_RNG && ENTROPY_GENERATOR with value n, but is currently being y-selected by the following symbols:
 - BT_LLL_VENDOR_NORDIC (defined at c:\Users\hiche\workspace\M01-NRF\build\subsys\bluetooth\controller\Kconfig. ll_sw_split:11), with value y, direct dependencies SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y), and select condition SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y)

error: Aborting due to Kconfig warnings

I don't understand this error knowing that the CPU NET configuration must be activated by enabling the BT.
However, to be able to change the data length I need to activate the BT_CTLR.

Thanks,

Hichem

36322.prj.conf

[Hung Bui]

Hi Hichem, 

Please be aware that when you compile a BLE application for nRF53 there are 2 applications compiled, one for the app core and one for the net core. Have a look here.

It's the hci_rpmsg application is built for the netcore. This contains the BLE controller stack. 

The configuration you made in the prj.conf will not affect the hci_rpmsg image. If you want to configure the netcore/controller to support longer data length you would need to create a hci_rpmsg.conf file and put it in child_image folder. 

Please have a look at the hci_rpmsg.conf file inside \nrf\samples\bluetooth\throughput\child_image

Make sure you do a pristine build after you add the file and re-flash the net core. 

[HichMenta]

Hi Hung Bui,

Thank you for your answer.

I was able to compile the project following your directions. I added the hci_rpmsg.conf in the child_image folder to set up the BT_CTLR.

However, with the NRF BLE application when trying to change the data length to 251 Bytes it stays locked at 27 Bytes. I tried on the peripheral device side to change the data length value by executing the function bt_conn_le_data_len_update in the connected callback. The data length is blocked at 27 Bytes.
As a reminder, I use the Nrf52840 dongle.

Thanks,

Hichem 3771.prj.confhci_rpmsg.conf

[Hung Bui]

Hi Hichem, 
Please capture a sniffer trace, we would need to see which side of the connection set it to 27. 

There could be a chance that the nRF52840 doesn't accept the long data length. 

Please capture the trace in both cases with CONFIG_BT_AUTO_DATA_LEN_UPDATE=y and CONFIG_BT_AUTO_DATA_LEN_UPDATE=n.

[HichMenta]

Hi Hung Bui,

I send you the traces with the two configurations.
It is the NRF53 which answers or sends 27 Bytes in parameter of LL_REQ.
I think that there is a problem of configuration between the CPU NET and the CPU APP.

data_length_with_AUTO_DATA_LEN_UPDATE.pcapngdata_length_without_AUTO_DATA_LEN_UPDATE.pcapng

[Hung Bui]

Hi Hichem, 

From the logs I can see that the central support 251 bytes datalength but the slave was responding with only 27 bytes. 
I suspect that the hci_rpmsg was not compiled with the updated value of the datalength. 
I would suggest to try compile the hci_rpmsg separately (with 251 bytes datalength configuration in the prj.conf) and flash it separately into the netcore. 

Please make sure you erased the netcore before the test. If you use nrfjprog you would need to use "--coprocessor CP_NETWORK"

I would suggest to test with our throughput sample in the SDK and capture a sniffer trace to see if Datalength is updated correctly. 

I also attached my own data throughput sample that based on the peripheral_uart sample. You can simply test the throughput using a phone or any central. Just need to enable notification CCCD to start the test. 

In the log you can see something like this:

0486.peripheral_uart_throughput.zip