This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC26X2R1: HCI_EXT_SetLocalSupportedFeaturesCmd() doesn't disable some features

Part Number: LAUNCHXL-CC26X2R1

Hello,

This is a follow up question to link

I'm using HCI_EXT_SetLocalSupportedFeaturesCmd() to change the stack features but some features do not get disabled (Ping, Privacy, Extended Scanner Filter Policies, Extended Advertising).  I'm not worried about the Extended Advertsing feature because we're using it in our Application so I'll want that enabled but I do want to disable Ping, Privacy and Extended Scanner Filter Policies.

Running a simple test, I wrote the following code:

const uint8_t llFeatureSet[8] = {0, 0, 0, 0, 0, 0, 0, 0};
ALLEGE(HCI_EXT_SetLocalSupportedFeaturesCmd((uint8*)&llFeatureSet[0]), HCI_SUCCESS);

When I connect to the device with btool, I get the following features:

[7] : <Rx> - 04:17:38.498
-Type : 0x04 (Event)
-EventCode : 0x003E (HCI_LE_GenericReportEvent)
-Data Length : 0x0C (12) bytes(s)
LE Event Code : 0x04 (4) (HCI_LE_ReadRemoteUsedFeaturesCompleteEvent)
LE Event Code : 0x04 (4) (HCI_LE_ReadRemoteUsedFeaturesCompleteEvent)
Status : 0x00 (0) (SUCCESS)
ConnectionId : 0x0000 (0)
Features : 0x00000000000010D0 (4304) (
Ping
Privacy
Extended_Scanner_Filter_Policies
Extended_Advertising)
Dump(Rx):
0000:04 3E 0C 04 00 00 00 D0 10 00 00 00 00 00 00

What would be overriding the selections I send into HCI_EXT_SetLocalSupportedFeaturesCmd()?  Are there compile flags that might be controlling this?

Thanks,

Dawn

  • Hey Dawn,

    I'm sorry you are seeing this. The timing of when this command is executed could be causing this behavior. Was the setLocalSupportedFeaturesCmd set before the connection was established? If you have some steps I can follow to try and reproduce this, this will help.

  • Hi Ammar,

    Yes, the call is before the connection was established.

    I imported the Simple Peripheral project and ran it as is.  When I establish a connection with btool, I see the first two bytes of the Features array to be 0xFF and 0x59.  I presume this represents the default feature set.

    I then change simple_peripheral.c by adding the following three lines in SimplePeripheral_init().  I add them after the call to GAP_DeviceInit().

    GAP_DeviceInit(GAP_PROFILE_PERIPHERAL, selfEntity, addrMode, &pRandomAddress);

    const uint8_t llFeatureSet[8] = {0, 0, 0, 0, 0, 0, 0, 0};
    hciStatus_t hciStatus = HCI_EXT_SetLocalSupportedFeaturesCmd((uint8*)&llFeatureSet[0]);
    SIMPLEPERIPHERAL_ASSERT(hciStatus == HCI_SUCCESS);

    // Initialize array to store connection handle and RSSI values
    SimplePeripheral_initPHYRSSIArray();

    When I establish a connection with btool, I see the first two bytes of the Features array to be 0xD0 and 0x10.  

    Hopefully, you can reproduce this.

    Dawn

  • Hey Dawn,

    Thanks for the details. I was able to reproduce this. Upon further investigation, I think this is intended behavior per the spec. Put simply, when the central reads the feature, it ignores the LE Ping bit (amongst others).

    If you look at page 3013 of the v5.2 spec (Section 4.6 Feature Support, Vol 6, Part B), the featureSet table shows a column titled "Valid from Controller to Controller". As you'll see, the items marked "N" here are the ones that are still returned by BTOOL after you made the modifications, which aligns with this theory. It looks like you may not have control of that feature in the feature set.

    It may be the case that if you disable LE Ping on the central side, then you can effectively "disable" it, but I haven't tested this to confirm. If the central side has it enabled, then it looks like the controller will use the local featureset and ignore the peer(peripheral) 's controller setting for that bit.

    Hopefully this makes sense, I apologize for any misdirection I provided in the other thread.

  • Hi Ammar,

    Thank you for pointing out the section of the spec that explains the bits will be ignored.  Since the bits are being ignored, it seems like the call to SetLocalSupportedFeatures should still set the bits as they are sent into the function so as to not cause confusion.  I say this because Bit Position 13 - LE Periodic Advertising has the same marking of N for 'VAlid from Controller to Controller' and I can't seem to set that bit so there is an inconsistency that adds to the confusion.  Anyway, I documented this information in our code so you can consider this issue closed.

    Dawn