Sending BT_HCI_OP_LE_TX_TEST_v4 DTM command doesn't work any more after ncs 2.6 update

[Jari P]

Hey,

After updating the nRF Connect SDK v2.60 (from 2.3.0) package an attempt to turn a BLE carrier ON by sending the BT_HCI_OP_LE_TX_TEST_v4 DTM command over the HCI interface by calling the bt_hci_cmd_send_sync() function just keeps on returning the -EOI (-5) error response (the status byte returned is BT_HCI_ERR_UNKNOWN_CMD = 1).

We have the nRF5340 chip in our device and this same test was working just fine before the update. On the BLE controller we are running For the test we have just added the following config settings to hci_ipc.conf (in ...\gitrepo\ourplatform\child_image\ folder).

Are you aware of any reason why the carrier test wouldn't work anymore with the new ncs version? Or are we missing some vital changes in the config of our product?

Thanks,

-Jari

[Sigurd Hellesvik]

Hi,

BT_HCI_OP_LE_TX_TEST_v4

Could you explain what you did to make this command work in v2.3.0 (if anything)?

Regards,
Sigurd Hellesvik

[Jari P]

Hi,

Our intention was to run RF tests with our device so we just added the following config lines to hci_ipc.conf file (in  the../ourdevice/child_image/ folder) to get the Zephyr BLE controller into use:

CONFIG_BT_LL_SW_SPLIT=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_DTM_HCI_TX_V4=y

And we have one more change in the ourdevice_macro_cpunet.dts (in ../ourdevice/boards/arm/ourdevice_macro/ folder: the timer0 definition ("&timer0 { status = "okay"; };") was commented out.

Regards,

Jari

[Jari P]

Here are the functions (handle_rf_test_data()->ble_test_start_carrier_tx()->ble_transmitter_test_v4_cmd():

static void handle_rf_test_data(rf_acceptance_prod_test_t const * const data)
{
switch(data->mode){
case RF_CARRIER:
{
ble_test_stop();
uint8_t channel = get_channel(data->freq);
int ret = ble_test_start_carrier_tx(channel, 0);
if (ret)
{
LOG_ERR("ble_test_start_carrier_tx returned: %i", ret);
}
break;
}
...
}
}

int ble_test_start_carrier_tx(uint8_t channel, uint8_t tx_power) {
transmitter_test_params_t params;
params.tx_channel= channel;
params.packet_payload = 0x11; //Vendor specific
params.test_packet_length = 0xff;
params.tx_power_level = tx_power;
params.cte_length = 0;
params.cte_type = 0;
params.phy = 0x01; //1M
return ble_transmitter_test_v4_cmd(&params);
}

int ble_transmitter_test_v4_cmd(transmitter_test_params_t * params)
{
struct net_buf* buf;
uint8_t packet[TRANSMITTER_TEST_V4_PAYLOAD_LENGTH];
int i = 0;
packet[0] = params->tx_channel;
packet[1] = params->test_packet_length;
packet[2] = params->packet_payload;
packet[3] = params->phy;
packet[4] = params->cte_length;
packet[5] = params->cte_type;
packet[6] = params->switching_pattern_length;
if(params->switching_pattern_length){
for(i = 0;i<params->switching_pattern_length; ++i){
packet[7+i] = params->antenna_ids[i];
}
}
packet[7+i] = params->tx_power_level;

buf = bt_hci_cmd_create(BT_HCI_OP_LE_TX_TEST_V4, 7+i+1);
if (!buf) {
return -ENOBUFS;
}

net_buf_add_mem(buf, packet, 7+i+1);

return bt_hci_cmd_send_sync(BT_HCI_OP_LE_TX_TEST_V4, buf, NULL);
}

And below is a screenshot of the function which catches the error (-5):

[Sigurd Hellesvik]

I eventually figured that the best way to approach this is for me to test it in a minimal sample.

So I created this one:

hci_test.zip

I first tested it with v2.5.2.
It returns OPcode 0x01 if I comment out child_image/hci_rpmsg.conf.
It returns OPcode 0x11 if I leave that in.
This seems to mean that the command is at least supported.

I test the same for v2.6.1, but with hci_ipc.conf instead, and that gives the same result.

Do you see the same from this sample?
Cause if this works, then it means that the command is indeed supported in v2.6.1.
And it gives you a good anchor to compare your project to.

[Jari P]

Hey,

I don't get your point.

Yet I have some good news. Regardless of the HCI command warning we are seeing in the syslog ("bt_hci_core: bt_hci_cmd_send_sync: opcode 0x207b status 0x01") after running the BT_HCI_OP_LE_TX_TEST_V4 I asked our RF guy to try if the operation still works e.g. if the carrier and/or modulated carrier gets turned ON. And to my surprise it indeed worked! Thus it seems that we can run/use BT_HCI_OP_LE_TX_TEST_v4 DTM command even it returns a warning. And all this with the version 2.6.1 or 2.6.0.

-Jari

[Sigurd Hellesvik]

Jari P said:

I don't get your point.

I tested the command on v2.6.x, and it works on my side.
This makes it seem like it is not an nRF Connect SDK v2.6.x issue, but related to configuration of your project.

If you now can test the example I created to see if that works on your side, and it works for you => Then you have a project that supports the command and one which does not support the command. => Comparing these two should make it easier to find out what is wrong with the one that does not support the command

[Jari P]

Thank for the example project. I have to try it in some phase. Yet at the moment it seems that we can use the 2.6.x versions regardless of the warning response we are observing.

I'll close this ticket now.