• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 51 subscribers
  • Views 1216 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Peripheral takes a long time to re-start sending advertisements after disconnect

Gary Sugar
Prodigy 160 points
Other Parts Discussed in Thread: CC2540

I have an application in which I have a central device (iPhone) that connects and disconnects fairly frequently to a peripheral device. I've found that the peripheral takes a long time (~ 30 seconds) to begin sending advertisements after it receives a disconnect from the central device. In other words, the peripheral is in the GAPROLE_WAITING state for 30 seconds before it changes back to the GAPROLE_ADVERTISING state. Is there a way to shorten the time it spends in the GAPROLE_WAITING state, to make it, say only 3 seconds, before it starts advertising again? I'm using version 1.4.0 of the BLE-CC254x SDK. 

Thanks,
Gary Sugar
  • 0
    TI__Guru** 105180 points
    Hello Gary,

    When I perform this procedure using the simpleBLEPeripheral default application on the TI reference HW (SmartRF05 board + CC2541EM module), I see advertising resume almost immediately following link termination. Can you describe your changes that led to this condition where it takes a long time to resume advertising?

    Best wishes
  • 0 in reply to JXS
    Prodigy 160 points

    Hi - 

    Thanks for getting back so quickly. We used the keyfob application as our starting point - not the simpleBLEPeripheral. What tool did you use to confirm how quickly it took for the simpleBLEPeripheral app to resume advertisements? Bluetool? We set breakpoints in the IAR debugger and found there was a 30 second delay between our app being in the GAPROLE_WAITING and  GAPROLE_ADVERTISING states. As a next step we will see whether the keyfob app has the same 30 second delay that our app as. If it doesn't, then we probably have a bug in our app. Will get back to you on this thread and let you know either way. 

    Gary

  • 0 in reply to Gary Sugar
    TI__Guru** 105180 points
    Hi Gary,

    You can see Advertising on the SmartRF05 LCD, and confirm likewise that Adv is enabled with Light Blue or any scanner app.

    The keyfob demo is not designed to auto-enable (Limited) Advertising whereas simpleBLEPeripheral (SBP) uses General (continuous) Advertising. Also, keyfob requires app level input to trigger Advertising, such as the key press. I suggest looking at how Adv is performed in SBP; this will hopefully allow you to find your issue.

    Best wishes
  • 0 in reply to JXS
    Prodigy 160 points

    Thanks for the info - this was very helpful. 

    I ran SBP and confirmed that there was very little delay between the invocation of the GAPROLE_WAITING and GAPROLE_ADVERTISING states. 

    I also found that the 30 second gap in between those two states in our keyfob-based code only happened when our peripheral device was in the GAPROLE_CONNECTED_ADV state before being disconnected. Is there a clean way we can prevent our device from ever entering the GAPROLE_CONNECTED_ADV state in the first place? I noticed that the SBP never enters that state as well - only the GAPROLE_CONNECTED state and we have no need to have our device sending adverts while connected.  

    Thanks,

    Gary

  • 0 in reply to Gary Sugar
    TI__Guru** 105180 points
    Hi Gary,

    This could happen if the GAP_MAKE_DISCOVERABLE_DONE_EVENT occurs after the connection is established. Could this be the case? If so, then you can just remove this state from peripheral.c since you indicated your device doesn't support connected advertising.

    I would use the CC debugger to confirm, though.

    Best wishes
  • 0 in reply to JXS
    Prodigy 160 points
    I'm sure it is the case because that's the only place in the code that sets the state to GAPROLE_CONNECTED_ADV. What would cause the device to receive a GAP_MAKE_DISCOVERABLE_DONE_EVENT though? And isn't there a cleaner way to workaround this issue than editing the SDK source file peripheral.c? Maybe I'll just use the call-out that gets called at the end of that function.
  • 0 in reply to Gary Sugar
    Prodigy 160 points

    The other important point I forgot to add is that the device is only going into the GAPROLE_CONNECTED_ADV in my app (which is again, based on the keyfob sample app) but not in the SBP sample app, which means that unlike my app, the SBP app is somehow not getting the GAP_MAKE_DISCOVERABLE_DONE_EVENT. What is it about SBP that makes it not get that event? I will of course try to solve this myself, but thought you TI guys might have a quick answer. Note that the central device I'm using to test both the SBP and my keyfob-based app is LightBlue running on an iPhone. 

    Thanks!!

    Gary

  • 0 in reply to Gary Sugar
    TI__Guru** 105180 points
    SBP does get the GAP_MAKE_DISCOVERABLE_DONE_EVENT, I can confirm with the CC Debugger. Set a breakpoint then enable Adv.

    In your project, if you enable Adv but do not initiate the connection from LB, you should be able to confirm that you get this event. I tried doing a CPU reset/halt in IAR, then initiated the connection in LB, then resumed the CC2540 but I wasn't able to replicate this state. The only thing I can think of is the connect request is getting processed before the GAP_MAKE_DISCOVERABLE_DONE_EVENT, but not sure how that is the case.

    Are there any other changes you've made related to GAP role functionality?

    Best wishes