none
BluetoothGATTRegisterEvent returns ERROR_INVALID_PARAMETER RRS feed

  • Question

  • Is there a way to find out why BluetoothGATTRegisterEvent returns ERROR_INVALID_PARAMETER? I am trying to establish a callback event and all the input parameters appear correct. In fact the code works for a different characteristic on the same device which supports 2 value change events on different characteristics. Is the offending parameter logged anywhere?


    oregonduckman

    Thursday, November 7, 2013 10:20 PM

Answers

  • Turns out there was a problem with the characteristic data in the firmware. In particular, IsNotifiable was disabled in characteristic 5 and even setting IsNotifiable to TRUE and IsWritable to TRUE still caused BluetoothGATTRegisterEvent to reject the original version of the firmware. Only changing the value IsNotifiable in the firmware to TRUE would allow BluetoothGATTRegisterEvent to succeed. If would be really helpful if MS would return more info than just INVALID_PARAMETER

    oregonduckman

    Friday, November 8, 2013 5:37 PM

All replies

  • please post your code

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, November 7, 2013 11:25 PM
  • As Doron said, if you post the snippet with the failing code we can be of more assistance, also what Service are you registering the ValueChange notification for? It will explicitly not work for things like Generic Attribute Service, Generic Access Service or HID services. All other services should be fine as long as the characteristic supports notifications or indications, in it's specification.

    Thursday, November 7, 2013 11:35 PM
  • The service is a modified version of the Simple Keys Service that comes with the TI mini dk.

    The code works as is for characteristic 4 (UUID 0xFFF4)/client characteristic configuration(0x2902) but fails for characteristic 4 (UUID 0xFFF5)/client characteristic configuration(0x2902) using the Gatt driver that comes with Windows 8/8.1 but works using HCI transport and the CDC driver (via BLE Device Monitor that comes with the TI mini DK).

    HRESULT hr = S_OK;
    bool bReturn = false;
    USHORT clientConfigDescIndex = 0;
    BTH_LE_GATT_DESCRIPTOR_VALUE clientConfigValue;

    ZeroMemory(&clientConfigValue, sizeof(clientConfigValue));

    // for this GATT service the event we want to register for lives in
    // the ClientCharacteristicConfiguration descriptor
    clientConfigValue.DescriptorType = ClientCharacteristicConfiguration;

    clientConfigValue.ClientCharacteristicConfiguration.IsSubscribeToNotification = TRUE;

    if ((hr = BluetoothGATTSetDescriptorValue(m_pCLEGattCharacteristic->GetGattDeviceHandle(), m_PBTH_LE_GATT_DESCRIPTOR, &clientConfigValue, BLUETOOTH_GATT_FLAG_NONE)) == S_OK)
    {
    // bind the event's callback to the event
    BLUETOOTH_GATT_VALUE_CHANGED_EVENT_REGISTRATION registration = { 0 };
    registration.Characteristics[0] = *m_pCLEGattCharacteristic->GetRawCharacteristicBuffer();
    registration.NumCharacteristics = 1;
    m_pCLEGattEventContext = new CLEGattEventContext(this, pEvent);
    if ((hr = BluetoothGATTRegisterEvent(m_pCLEGattCharacteristic->GetGattDeviceHandle(), CharacteristicValueChangedEvent, (PVOID)&registration, GattCallback, (PVOID)m_pCLEGattEventContext, &m_ValueChangeEventReg, BLUETOOTH_GATT_FLAG_NONE)) != S_OK)
    {
    delete m_pCLEGattEventContext;
    m_pCLEGattEventContext = NULL;
    SetLastGattError(_T("AddEvent: "), (wchar_t *)_com_error(hr).ErrorMessage());
    }
    else
    {
    bReturn = true;
    }
    }
    else
    {
    SetLastGattError(_T("AddEvent: "), (wchar_t *)_com_error(hr).ErrorMessage());
    }
    return bReturn;


    oregonduckman

    Thursday, November 7, 2013 11:56 PM
  • The code above is of the function in which you actually register the event, it would be useful to actually see how you obtain the parameters passed to those functions.

    One observation that I have is that when you call BluetoothGATTSetDescriptorValue, you use the m_PBTH_LE_GATT_DESCRIPTOR member variable to set the descriptor’s value, depending on how that variable is initialized, you might be trying to set the descriptor of a different characteristic, which might result in the INVALID_PARAMETER error you’re seeing. Also from this it’s not entirely clear what m_pCLEGattCharacteristic->GetRawCharacteristicBuffer returns, I am assuming it’s the correct pointer to a PBTH_LE_GATT_CHARACTERISTIC object, but actually seeing the initialization code can help validate those assumptions.

    Feel free to post a few more snippets about where and how these parameters are initialized.

    Thank you,

    Florin

    Friday, November 8, 2013 5:24 PM
  • Turns out there was a problem with the characteristic data in the firmware. In particular, IsNotifiable was disabled in characteristic 5 and even setting IsNotifiable to TRUE and IsWritable to TRUE still caused BluetoothGATTRegisterEvent to reject the original version of the firmware. Only changing the value IsNotifiable in the firmware to TRUE would allow BluetoothGATTRegisterEvent to succeed. If would be really helpful if MS would return more info than just INVALID_PARAMETER

    oregonduckman

    Friday, November 8, 2013 5:37 PM
  • Even with a slightly more descriptive error code, there's only so much information that can be conveyed with a simple status code, but we will take your feedback into consideration.

    Thank you,

    Florin

    Friday, November 8, 2013 5:51 PM
  • But why not let the server reject the parameter? I don't recall anything in the LE spec that says the HOST has to validate the parameters. 

    oregonduckman

    Friday, November 8, 2013 5:59 PM
  • Even though the event registration is now working and events are being received the data is garbage. I checked it against LightBlue on the iPad and the event buffer returned there is perfect and the event buffer is valid when using HCI as the transport via the CDC driver provided by TI.

    oregonduckman

    Friday, November 8, 2013 11:40 PM