CC2541: Sometime the data sent over the GATT_Notification shifted

Part Number: CC2541

Hello,

In our company we are using TI CC2541 chip and the latest BLE Stack 1.5.0 for streaming data over the BLE.
For this purpose we are using GATT_Notification mechanism and our own protocol for streaming.

We have faced with problem where the data in the L2CAP packet sometime shifted on 3 bytes backward.

Here is the piece of code we are using to send the data:
...
static void Profile_NotifyStreamingCB( linkDBItem_t *pLinkItem )
{
    if ( pLinkItem == NULL )
        return;

    if ( pLinkItem->stateFlags & LINK_CONNECTED )
    {
        uint16 value = GATTServApp_ReadCharCfg( pLinkItem->connectionHandle, ProfileStreamingOutConfig );

        if ( value & GATT_CLIENT_CFG_NOTIFY )
        {
            gattAttribute_t *gattAttribute = GATTServApp_FindAttr(ProfileAttrTbl, SERVAPP_NUM_ATTR_SUPPORTED, ProfileStreamingOut);
            if (gattAttribute == NULL)
                return;

            attHandleValueNoti_t noti;
            noti.handle = gattAttribute->handle;
            noti.len = ProfileStreamingOutLen;
            noti.pValue = GATT_bm_alloc(pLinkItem->connectionHandle, ATT_HANDLE_VALUE_NOTI, ProfileStreamingOutLen, NULL);
            if (noti.pValue == NULL)
                return;

            VOID osal_memcpy( noti.pValue, ProfileStreamingOut, ProfileStreamingOutLen );

            bStatus_t reason = GATT_Notification( pLinkItem->connectionHandle, &noti, FALSE );

            // cleanup out buffer after the job done
            VOID osal_memset(ProfileStreamingOut, 0, ProfileStreamingOutLen);
            ProfileStreamingOutLen = 0;

            if ( reason != SUCCESS )
            {
                GATT_bm_free(( gattMsg_t *)&noti, ATT_HANDLE_VALUE_NOTI );
                return;
            }
        }
    }
}

void Profile_NotifyStreaming( void )
{
    linkDB_PerformFunc( Profile_NotifyStreamingCB );
}

void Profile_SendStreamingData( const uint8 id, const uint8 counter, const uint8 retry, const uint8 * data, const uint8 len )
{
    ProfileStreamingOut[0] = id;
    ProfileStreamingOut[1] = SET_RETR(retry) | SET_COUNT(counter);
    ProfileStreamingOutLen = 2;

    if (len)
    {
        osal_memcpy(&ProfileStreamingOut[2], data, len);
        ProfileStreamingOutLen += len;
    }

    Profile_NotifyStreaming();
}
...

As you can see we have fixed (or even hardcoded) offsets for our internal message structure.
Anyhow in a rare cases, during the high load the data comes shifted to the other side (the other side is an App on IOS/Android).

We have checked this against the sniffer - the sniffer shows that our BLE Peripheral device send such "corrupted" packet.

Could it be that the user data of 20 bytes has been copied to message (Bluetooth L2CAP - Attribute Protocol) ignoring the header (which is exactly 3 bytes)
and then the header has been copied upon it, finally the crc has been calculated?

So, the packet looks well from the point of L2CAP view, but first 3 bytes has been lost.