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