USB-KW41Z - FSCI - BLE Notifications not propagated / No NotificationCallback

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB-KW41Z - FSCI - BLE Notifications not propagated / No NotificationCallback

1,577 Views
chilipp
Contributor III

Hello,

I'm using the "ble_fsci_blackbox" image with the USB-KW41Z and have a problem with receiving gatt notifications.

The device which the USB-KW41Z is connected to have 2 characteristics, one for data transmission towards the gatt-server (only write permissions) and one for receiving notifications from the gatt-server (only notify permissions).

Now the Problem is, the notification-only characteristics does not have a CCCD to write to / enable notifications as the client is authenticated before (by writing first to the write-only-characteristic) and therefore must be able to handle notifications (gatt server don't have to distinguish whether a client is able to process indications or not - it just sends one if authentication was successful).

While sniffing the BLE traffic I can see a "ATT Handle Value Notification" package on the air from the gatt-server towards the USB-KW41Z, but no NotificationCallback/Indication get triggered.

I registered the "GATTClient-RegisterNotificationCallback.Request" before any GATT operations and also (the GATT-Table is static and I actually know all the handles so first i tried directly writing to the handle) tried first discovering all services/characteristics (I thought, maybe internals need to know about all characteristics to be able to forward notifications on characteristic-handles) but with no success.

I'm expecting "GATTClient-Notification.Indication" but none is received although there is one "in the air".

I'm unable to change the behavior of the gatt-server / unable to implement a CCCD for the characteristic as it's given.

Labels (2)
0 Kudos
4 Replies

1,310 Views
chilipp
Contributor III

So I hacked myself into the FSCI-Blackbox sample application by compiling it by myself and running on the device and when I register a Notification-Callback by myself (i.e not "enable" it via FSCI but register one directly in code) I do reach my breakpoint - so the Notification is received and handle by the BLE-Stack but is NOT FORWARDED BY FSCI EVEN AFTER REGISTERING/ENABLING NotificationCallbacks!

It seems to me that is a bug in the fsci-ble implementation ...

The FSCI-BLE functions are referenced by "lib_ble_4-2_host_fsci_cm0p.a"  - is there any code for this or is it only binary included within the SDK?

0 Kudos

1,310 Views
chilipp
Contributor III

My workaround for this issue is following:

I added inside BleApp_Init() of ble_fsci_blackbox sample my own notification callback handler notificationCallback(...) and inside that callback-function I send the expected Notification-Indication ...

Should be fixed in lib_ble_4-2_host_fsci_cm0p.a !

void BleApp_Init(void)
{
    /* Init serial manager */
    SerialManager_Init();

    /* Init FSCI */
    FSCI_Init((void*)fsciConfigStruct);

    /* Register BLE handlers in FSCI */
    fsciBleRegister(0);

    /* Register my own Notification-Callback */
    fsciBleSetGattClientNotificationCallback(notificationCallback);

#if gHkb_d
    PORT_HAL_SetMuxMode(PORTC,0u,kPortPinDisabled);
    PORT_HAL_SetMuxMode(PORTC,1u,kPortPinDisabled);
#endif
}

void notificationCallback(
     deviceId_t  deviceId,                   /*!< Device ID identifying the active connection. */
     uint16_t    characteristicValueHandle,  /*!< Handle of the Characteristic Value attribute to be notified. */
     uint8_t*    aValue,                     /*!< The Characteristic value array. */
     uint16_t    valueLength                 /*!< Value array size. */
) {
 clientPacketStructured_t*   pClientPacket;
 uint8_t*                    pBuffer;

    /* Allocate the packet to be sent over UART */
    pClientPacket = fsciBleAllocFsciPacket(
      gFsciBleGattOpcodeGroup_c, // opCodeGroup
      gBleGattEvtClientNotificationOpCode_c, // opCode
   sizeof(deviceId_t) + 2 * sizeof(uint16_t) + valueLength // dataSize
 );

    if(NULL == pClientPacket)
    {
        return;
    }

    pBuffer = &pClientPacket->payload[0];

    // deviceId
    *pBuffer = deviceId;
    pBuffer++;

    // characteristicValueHandle
    pBuffer[0] = (uint8_t)((characteristicValueHandle) & 0xFF);
    pBuffer[1] = (uint8_t)(((characteristicValueHandle) >> 8) & 0xFF);
    pBuffer += 2;

    // valueLength
 pBuffer[0] = (uint8_t)((valueLength) & 0xFF);
 pBuffer[1] = (uint8_t)(((valueLength) >> 8) & 0xFF);
 pBuffer += 2;

 // value
 FLib_MemCpy(pBuffer, aValue, valueLength);
 pBuffer += valueLength;

 FSCI_transmitFormatedPacket(pClientPacket, 0);
}
0 Kudos

1,310 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Chilipp,

What is the version that you are working on? Are you using the FRDM or the USB Dongle?

DId you look at the App_GattClientNotificationCallback? AppMain.c

Regards,

Mario

0 Kudos

1,310 Views
chilipp
Contributor III

Hi Mario,

as the title states I am using the USB-Dongle (USB-KW41Z) with SDK Version: KSDK 2.2.0 (2019-01-16).

I have not looked further at the App_GattClientNotificationCallback because to me it seems this is only for dispatching the notification from the Host-Thread to the Application-Thread.

The issue is already fixed by my approach and is working - so I think I will "not change my running system" :smileywink:

0 Kudos