CC2640R2F: GAPROLE state locks up BLE operation

Greg Lantz

Part Number: CC2640R2F

I have an application on the 2640 that communicates with a smart phone app. I have discovered that if the phone goes out of range (or the BLE communication is otherwise prevented - phone or my device goes into an RF chamber that prevents communication) the 2640 BLE operation gets a state change event with a new state of GAPROLE_WAITING_AFTER_TIMEOUT. The state never changes. When I bring the phone back into range, the app indicates the connection has been dropped. The 2640 does not resume advertising. The code in simple_peripheral.c that handles this state is as follows:

case GAPROLE_WAITING_AFTER_TIMEOUT:

attRsp_freeAttRsp(bleNotConnected);

Display_print0(dispHandle, 2, 0, "Timed Out");

// Clear remaining lines
Display_clearLines(dispHandle, 3, 5);

#ifdef PLUS_BROADCASTER
// Reset flag for next connection.
firstConnFlag = false;
#endif // PLUS_BROADCASTER
break;

I am using SDK version 4.10.0.10. I guess there needs to be some processing on my part to exit this state to resume advertising?

over 4 years ago

0 Clément over 4 years ago

TI__Guru** 101460 points

Hi Greg,

If I understand properly, the device is not advertising right before changing it state to GAPROLE_WAITING_AFTER_TIMEOUT. Am I correct?

In your case, you probably want to turn back on the advertisements within the "case GAPROLE_WAITING_AFTER_TIMEOUT:". The only challenge is to not blindly turn back on the advertisement when you reach this state, if not it would cause some issues.

Here a code snippet you could leverage:

case GAPROLE_WAITING_AFTER_TIMEOUT:

  attRsp_freeAttRsp(bleNotConnected);

  Display_print0(dispHandle, 2, 0, "Timed Out");

  // Clear remaining lines
  Display_clearLines(dispHandle, 3, 5);

  #ifdef PLUS_BROADCASTER
  // Reset flag for next connection.
  firstConnFlag = false;
  #endif // PLUS_BROADCASTER

  // When relevant turn back on advertising
  if(isAdvAllowed){
    GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advertReEnable);
    Display_print0(dispHandle, 2, 0, "Advertising");
  }
  
break;

Once again, your challenge is to find how/when "isAdvAllowed" should be set to true. For a first evaluation, you may want to keep this boolean always TRUE.

Let us know if it helps,

Kind regards,

0 Greg Lantz over 4 years ago in reply to Clément

Intellectual 700 points

You are correct, the device is in a connection when this occurs. Can you provide any guidance on when it would be inappropriate to turn advertising back on?

A side note: If I have the advertising rate at something around 1 second or less, this problem does not occur. For power consumption purposes, the device usually sets the advertising rate to 10 seconds, and then the problem occurs.

Thanks for your help.

I did put in code to renable advertising without the boolean, and so far it seems to work reliably. I'm just concerned about when reenabling might be a problem.

0 Clément over 4 years ago in reply to Greg Lantz

TI__Guru** 101460 points

Hi Greg,

Greg Lantz said:
Can you provide any guidance on when it would be inappropriate to turn advertising back on?

I was thinking about some cases where the state is changed to GAPROLE_WAITING_AFTER_TIMEOUT but you don't want to turn back on the advertisements after (because you want to save power, wait for an external event to turn back on the advertisements, etc.).

Greg Lantz said:
I did put in code to renable advertising without the boolean, and so far it seems to work reliably. I'm just concerned about when reenabling might be a problem.

Great! Thank you for mentioning it.

Best regards,

0 Greg Lantz over 4 years ago in reply to Clément

Intellectual 700 points

Thanks for your help! It seems that I have a solution!

Bluetooth®︎

Bluetooth forum

CC2640R2F: GAPROLE state locks up BLE operation