1) The Master connects to the slave, and establishes link layer encryption.
2) After exchanging BLE data at about 4-5 KB/s for several seconds, the connection is lost.
a. Just prior to the loss, the Master transmits LLCP Feature Response
i. We don’t know why the CC256x is transmitting this – the trace shows no corresponding request from the slave
ii. In this instance, the Feature Response has a valid payload (See Ellisys Trace #1 below)
3) The Master attempts multiple times to reconnect, but reconnection fails.
a. The Connection is successful.
b. Connection parameter update is successful.
c. The master issues “Encryption Start” to the slave (See Ellisys Trace #2 below)
i. There is no response from the slave, but the Master now periodically transmits “LLCP Feature Response”. We suspect this is not supposed to happen.
ii. However, the response PDU is now invalid – the payload length has been truncated from 12 bytes (valid) to 5.
iii. Debug info on the slave side indicates that the slave terminated the connection due to a MIC failure (0x3D). That shouldn’t happen before encryption is established.
d. Then the Master drops the connection due to a Supervisor Timeout
e. Steps a-d repeat indefinitely. This scenario leaves the Master unable to reconnect.
4) In all loss-of-connections above, the slave BLE stack reports the reason for the disconnect as 0x3D “Connection Terminated Due to MIC Failure”. We don’t see how that fits with the scenario in 3c above.
Given that the version of the BTS script makes a difference, and the traces show the master generating LL messages that are unexpected and appear to be incorrectly formatted, we don't see this pointing to the TI BT stack or the application FW.
Ellisys Trace #1:
Ellisys Trace #2: