You are here

Duplicated indicate after connection | Cypress Semiconductor

Duplicated indicate after connection

Summary: 3 Replies, Latest post by Enpa on 24 Oct 2016 01:27 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
Enpa's picture
User
3 posts

 

I am developing a device based on the CYBLE-022001-00 with BLE Stack V3.10

The device is a Central GATT Client on a custom profile.
Scanning works fine and I can connect to the peripheral.
I enable indication on that peripheral, and that seems to work, too.

I write a command to the RX-characteristic of the peripheral, the peripheral performs some tasks and writes a response to the TX-characteristic, which causes an indication to be issued at the central.

I am using two different commands, let's call them L ("long") and S ("short"). The length of the commands is the same, but the generated response in 18 bytes for S and 21 bytes for L.
MTU is 20 bytes.
Hence I get two indications for L and a single one for S. Let's call these response packets [1x] and [2x], where x is S or L to identify the command that generated the packet.

This is the behavior I experience:

  • Start up the device, load the stack, perform a scan
  • Connect to the peripheral
    • Send L
      • Indication: [2L][1L][2L]
    • Send L
      • Indication: [1L][2L]
    • Send L
      • Indication: [1L][2L]
  • Disconnect from the peripheral
  • Re-connect to the peripheral
    • Send L
      • Indication: [2L][1L][2L]
    • Send L
      • Indication: [1L][2L]
    • Send S
      • Indication [1S]
    • Send S
      • Indication [1S]
  • Disconnect from the peripheral
  • Re-connect to the peripheral
    • Send S
      • Indication [1S][1S]
    • Send S
      • Indication [1S]
    • Send S
      • Indication [1S]
  • Disconnect from the peripheral
  • Re-connect to the peripheral
    • Send L
      • Indication [1S][1L][2L]
    • Send L
      • Indication [1L][2L]
    • Send L
      • Indication [1L][2L]
    • Send S
      • Indication [1S]
    • Send L
      • Indication [1L][2L]
  • Disconnect from the peripheral
  • Re-connect to the peripheral
    • Send S
      • Indication [2L][1S]

Summary: the first response after connection starts with a erroneous indication packet. This packet contains the payload of the last indication received before disconnection. If there was no previous connection, then the packet contains the payload of the last packet of the current response. All subsequent responses are correct.

Any idea on what could cause this strange behavior?

For completeness, here is how I get the indications:

switch (event)
{
   // all other cases omitted for the sake of readability

   case CYBLE_EVT_GATTC_HANDLE_VALUE_IND:
            indicationResponse = (CYBLE_GATTC_HANDLE_VALUE_NTF_PARAM_T *)eventParam;
            
            LL = indicationResponse->handleValPair.value.len;
            
            // debug info:
            for (ii = 0; ii < LL; ii++)
            {
                UART_UartPutChar(indicationResponse->handleValPair.value.val[ii]);
            }
            
            //rxHandler(indicationResponse);
            
            CyBle_GattcConfirmation(cyBle_connHandle);      // send ACK on indication

            break;

}

Normally I would do some computation on the response, but here I commented out the call to the rxHandler to simplify the problem.

Here is how I disconnect the device from the peripheral:

void requestDisconnect()
{
    if (CyBle_GetState() != CYBLE_STATE_CONNECTED)
        return;
    
    CyBle_GapDisconnect(cyBle_connHandle.bdHandle);
    
    txCharHandle             = 0;                /* Handle for the TX data characteristic */
    rxCharHandle             = 0;                /* Handle for the RX data characteristic */
    txCharDescHandle         = 0;                /* Handle for the TX data characteristic descriptor */
    bleUartServiceHandle     = 0;                /* Handle for the BLE UART service */
    bleUartServiceEndHandle  = 0;                /* End handle for the BLE UART service */
    mtuSize                  = CYBLE_GATT_MTU;   /* MTU size to be used by Client and Server after MTU exchange */
    infoExchangeState   = INFO_EXCHANGE_START;
    notificationEnabled = false;
    
    return;
}

Any help is greatly appreciated!

Kind regards, Enpa

mady's picture
Cypress Employee
967 posts

Hi Enpa,

This behavior is strange. Before disconnection, did the server receive the confirmation for the last indication it sent?

Also, upon receiving disconnect event, can you please do CyBle_SoftReset (). This will reset the BLE Stack.

Regards,

- Madhu Sudhan

Enpa's picture
User
3 posts

Hi Madhu

Thank you for your answer.

I cannot check if the server got the confirmation for all indications, but I am pretty sure that I send. Here is the code of the handler for the event CYBLE_EVT_GATTC_HANDLE_VALUE_IND:

case CYBLE_EVT_GATTC_HANDLE_VALUE_IND:
            
            indicationResponse = (CYBLE_GATTC_HANDLE_VALUE_NTF_PARAM_T *)eventParam;

            if(indicationResponse->handleValPair.attrHandle != txCharHandle)
                break;
            
            LL = indicationResponse->handleValPair.value.len;
            
            // debug info:
            for (ii = 0; ii < LL; ii++)
            {
                UART_UartPutChar(indicationResponse->handleValPair.value.val[ii]);
            }
            
            CyBle_GattcConfirmation(cyBle_connHandle);      // send ACK on indication
            CyBle_ProcessEvents();
            
            break;

 

I tried using CyBle_SoftReset() after receiving the event CYBLE_EVT_GAP_DEVICE_DISCONNECTED, but that leads to an error when I try to connect again to the peripheral: my device stays forever in CYBLE_STATE_CONNECTING.

I think that I can solve the problem by sending a command after connection and discarding the response. All subsequent responses are correct. But this is just a workaround because time to market is tight. I don't feel really comfortable with it without knowing what goes wrong...

Kind regards, Enpa

Enpa's picture
User
3 posts

One more thing...  I noticed something interestig. Have a look at the attached picture:

After resetting the peer device, the problem isn't there.

After resetting the CYBLE-022001-00 (hard reset using the hardware pin or soft reset of the BLE Stack) the problem is still there.

This does looks to me like the problem is in the peer device. What do you think?

Kind regards, Enpa

Log in to post new comments.