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.

BLE Stack Goes Awry

Other Parts Discussed in Thread: CC2541, TPS62730

This bug has been dogging me for months, can't connect to the CC2541 peripheral without resetting it.  It's been difficult to debug because it happens infrequently, but I've finally figured out what's happening and hope someone at TI can have a look at the ble stack.

Normal operation:  The device continually advertises at a rate of every 2 seconds.  An iPhone connects to the device.  The peripheral queries some sensors and sends notifications to the iPhone at a regular rate.  After some time the iPhone disconnects and the device goes back into advertising mode.  For the most part this works as expected.  But every once in a while the device doesn't start advertising again after the iPhone has ended the connection.

I monitor the GAP state via the state change callback function and turn on an LED when it goes into advertising mode.  When it fails I can see by the LED that it thinks it's in advertising mode, but there are no scannable packets.  The device has a TPS62730 regulator so I can see by the dip in the supply voltage when it's sending the advertising packet, during normal operation this occurs every 2 seconds.  When the device fails whilst transitioning to advertising mode, the supply voltage dips for several seconds before going high.  After that it dips similar to when advertising, but not at 2 second intervals, more like every 5 seconds, but at an irregular rate.

I wasn't sure if the processor was still running, so I enabled a 5 second task that toggles an LED.  Indications are that the firmware is running as normal aside from the ble stack.

The trigger for the failure seems to be back to back interrupts from the sensors on the device.  There is a chance that the stack won't transition properly to advertising mode If the iPhone disconnects whilst the interrupts are occurring.  The series of interrupts completes successfully, no hanging, no apparent problems.  A notification is sent when the interrupts complete, I assume that this is happening, although the device will no longer be in a connected state.  I thought that maybe sending a notification whilst not connected would cause a problem, so I tried monitoring the connection state and wouldn't send the notification unless connected.  But the stack still goes awry.

I think that maybe the interrupts are somehow disrupting the stack timing.

The device uses POWER_SAVING but the problem persists when this is disabled.

I'm using the latest 1.3.2 stack.

Thanks

Dan

  • Hi Dan,

    I can't really say what causes this. Perhaps some timing issue as you say. You could perhaps wait some time before re-enabling advertising after a disconnect?

    Do you get a callback (in the user application) to the peripheralStateNotificationCB::GAPROLE_ERROR case when it fails? How about peripheral.c's case GAP_MAKE_DISCOVERABLE_DONE_EVENT in gapRole_ProcessGAPMsg() There's a check for SUCCESS, that should make the GAPROLE_ERROR call.

    Best regards,
    Aslak 

  • Thanks Aslak,

    The callback indicates GAPROLE_ADVERTISING, there is no GAPROLE_ERROR.

    I've followed your suggestion and only re-enable advertising once the interrupts are completed.  This appears to be a useful work-around.

    Dan