I did some stress test to test the connection between iOS7 device and
our MSP430+CC2564 based BLE peripheral ( running Stonestreetone v1.4 stack).
The test App running on iOS7 simply repeats following activities continuously in every 2 second interval:
*) Connect with BLE device
*) Discover service and characteristics, perform some GATT read/write
*) Disconnect
I have some interesting findings I would like to share with fellow engineers.
----------------------- iOS7 BLE --------------------------------------
On iOS7 side, after repeatedly connection and disconnection with BLE peripheral
after 3~ 7 minutes, iOS7 would fail to discover GATT service after making a connection.
Packet sniffers shows that iOS7 is doing some weird thing after connection,
it keeps sending LL_Version packet instead of discover ATT attributes.
----------------------- TI/SS1 BLE --------------------------------------
On Stonestreeone stack side, under stress test sometimes the stack would
enter a zombie status, it thinks it's in connected status, but its peer
(iOS7 device) has already disconnected from it, therefore, iOS7 would not
be able to connect with the BLE device any more.
A normal sequence of events from Stonestreetone BLE stack should be
A) etLE_Connection_Complete
B) etGATT_Connection_Device_Connection
C) GATT Transcations
D) etGATT_Connection_Device_Disconnection
E) etLE_Disconnection_Complete
In short, correct sequence of events should be: Idle -> A->B->C ->D->E -> Idle ->...
From UART log, I can observe that the zombie status happened due to incorrect event sequences.
Scenario 1)
Idle -> B --------> zombie
Somehow event B) triggers even before event A), it stays here forever although
iOS7 did not connect successfully (normally sniffer shows the link layer error code 0x13 or 0x14),
and could not connect anymore since "the line is busy" from BLE devcie perspective.
Scenario 2)
Idle -> B -> A -> B -------> zombie
Incorrect sequence of events, similar to scenario 1), not be able connect to it any more.
Scenario 3)
Idle -> B -> C -> Idle -> A ->B -> C -> D -> E -> Idle
Similar to Scenario 1), but it is followed by C, then back to Idle then have normal
sequence of events, it fully recovered and can be connected to again.
