Link disconnection questions

Eyal Lasko

Hello,

I use GAPRole_TerminateConnection() to terminate a link immediately after connection was created.

However, I see that the link remains connected so I'm obviously missing something here... :~\

Follow is the disconnect method:

void BLEDisconnect()
{
	uint8 advert;
	bStatus_t status;

	status = GAPRole_TerminateConnection();	// disconnect link 
	advert = false;
	GAPRole_SetParameter( GAPROLE_ADVERT_ENABLED, sizeof( uint8 ), &advert );	// force stop advertising
}

This code is being called within osal event that has been triggered upon receiving GAPROLE_CONNECTED event in peripheralStateNotificationCB() in the following manner:

static void peripheralStateNotificationCB( gaprole_States_t newState )
{
  switch ( newState )
  {
    case GAPROLE_STARTED:  {
            // do something
	    break;

    case GAPROLE_ADVERTISING:
            // do something
	    break;

    case GAPROLE_CONNECTED:
            // do something
	    break;
   }

   StateChangeMessage_t	*msgPtr;
   msgPtr = (StateChangeMessage_t*)osal_msg_allocate(sizeof(StateChangeMessage_t));
   if(msgPtr)
   {
	msgPtr->Header.event = STATE_CHANGE_MESSAGE_TYPE;
	msgPtr->Payload.gapState = newState;
	osal_msg_send(peripheral_TaskID , (uint8*) msgPtr);    // when creating a connection osal_message is sent. 
       // The message processing loop intercepts the message and calls to BLEDisconnect() described above.
      // Is there any chance that the message is being processed BEFORE
   }
  gapProfileState = newState;
}

My questions regarding link termination are:

1. Is GAPRole_TerminateConnection() executed immediately when called or its deferred by the stack ?

2. If deferred, can it be cancelled before being executed ?

3. If deferred, Is it scheduled by the BLE stack using osal-like scheduling (non-preemptive) or is it done in a more 'preemptive manner' using HW interrupts ?

Another general BLE question regarding re-connection of a terminated link:

4. If link was terminated by the peripheral as described above and supervision timeout has not elapsed, can the peripheral re establish connection without advertising ?

Many thanks for any support

over 10 years ago

0 Eyal Lasko over 10 years ago

Expert 2300 points

Further investigating the issue above I came across the following code in peripheral.c:

(note line #32-35 of the quoted code)

static void gapRole_ProcessGAPMsg( gapEventHdr_t *pMsg )
{
  uint8 notify = FALSE;   // State changed notify the app? (default no)

  switch ( pMsg->opcode )
  {
.
.
.
    case GAP_LINK_TERMINATED_EVENT:  // line# 1094 in peripheral.c
      {
        //      some stuff here.
        //

        // Go to WAITING state, and then start advertising
        if( pPkt->reason == LL_SUPERVISION_TIMEOUT_TERM )
        {
          gapRole_state = GAPROLE_WAITING_AFTER_TIMEOUT;
        }
        else
        {
          gapRole_state = GAPROLE_WAITING;
        }

        notify = TRUE;
        
        // Check if still advertising from within last connection.
        if ( gapRole_AdvEnabled)
        {
          // End advertising so we can restart advertising in order 
          // to change to connectable advertising from nonconnectable.
          VOID GAP_EndDiscoverable( gapRole_TaskID );
        }
        else  // Turn advertising back on.
        {
          gapRole_AdvEnabled = TRUE;  /////// <<<===  ###  Does terminating a link ALWAYS turns on advertising ???   ////////////////
          VOID osal_set_event( gapRole_TaskID, START_ADVERTISING_EVT);
        }
        gapRole_ConnectionHandle = INVALID_CONNHANDLE;
      }
      break;

it seems that after terminating a link advertising is always re-initiated (regardless of GAPROLE_ADVERT_OFF_TIME =0 setting )

Is there a way to terminate a link and keep it terminated ?

Thanks in advance

0 Aslak N. over 10 years ago in reply to Eyal Lasko

TI__Mastermind 23440 points

Hi,

GAP_Terminate will follow the spec and await a response to TERMINATE_IND. To disconnect immediately, use the extension command HCI_EXT_DisconnectImmedCmd( uint16 connHandle );. This will not tell the Master that we've disconnected so it will remain connected until timed out on supervision timeout.

You have come across a bug there. You can however disable advertising in the GAPROLE_WAITING callback (which is executed before the advertising starts again).

Best regards,
Aslak

Bluetooth®︎

Bluetooth forum

Link disconnection questions