CC2642R: Troubleshooting Disconnection Issues

Hello Marie,

Thanks for the quick response. I spoke with tech support from the company that makes the sniffer and they pointed a few things out about the tool that I didn't know. On the "unfiltered" tab I can now see that the master device is initiating, and continuing connection events, the packets just have CRC errors. These aren't displayed in the screenshot of the LE Data tab I posted because of the CRC errors. This makes it look like the slave device is initiating it's own connection events.

I have another tangentially related question: are there any known issues with the CC2642 not responding to CONNECT_IND's, specifically for BLE stack v2.2?

We're currently working on phasing out our older hardware, but that's a work in progress, so we still have a lot of folks (internal engineering use only) using hardware with Rev C silicon. While chasing down this disconnection issue, which we see on both the devices with Rev C and Rev E silicon, we caught some sniffer traces of the peripheral repeatedly failing to connect / respond to CONNECT_IND's. So far we haven't captured this on the Rev E (SDK 3.1) devices, but they haven't been tested as thoroughly yet either. If there aren't any known issues with the older stack, we'll have to see if we can reproduce the issue on the newer hardware and go from there I suppose. 

Thanks,

Josh

Hi Tim, I am taking over the CONNECT_IND issue from Josh and have new information to add.  This issue has been logged using the 3.1 and 2.2 stacks so it doesn't appear to be related to stack version.   What we are seeing is that the next packet after a CONNECT_IND sent to the same access address has a CRC error as shown in the logs below.  When that occurs we never get connected to the peripheral device.   It appears to be sent within the timing window defined by the master as well so I have checked that avenue for potential issues.  We are using 1.25ms for the txWindowSize and 0 as the txWindowOffset.   The txWindow delay is 1.25ms per spec.  According to the BLE spec if that first packet has a CRC error, it still defines the anchor point.  We are wondering if the CRC error that occurs is possibly causing the TI stack to do something other that what is in the spec? 

Thanks in advance for any assistance you can provide, 

Tim W.

Hi Tim, here is the entire log per your request.

RC_Not_resp_1.zip

Hi Tim C., have you had a chance to investigate the logs I posted or do you have any updates?

Thanks in advance,

Tim W.

Hi. It looks like what you are point to can be explained by 2 scenarios:
1. the scenario you decsribed
2. the slave never saw the connection request

I'm leaning toward the second explanation because it appears that the advertisement that the connection request was sent to in the frame you were referring to (frame 10243, address 0x806fb0eee059) continues advertising at its 100 ms advertising interval after the connection request is sent.

It is normal for this to happen sometimes if there is a lot of interference or over-the-air traffic. That being said, it should not happen frequently in a clean environment.

Is the central device your own hardware or is this a TI board?

Hi Tim C., the hardware is custom hardware in this case. 

Let me see if I understand scenario 2.   Since the next advertisement from the peripheral is at the 100ms interval in the log, this would suggest that the peripheral never saw the connection indication or the next advertising interval is not likely to have been on the 100ms boundary correct?  If it had seen the connection indication, it would have then used the Link Layer connection supervision timer during connection establishment which the spec says is 6*connInterval (7.5ms in our case) before giving up and starting advertising again.  So in this case, it appears the peripheral was never looking for the master's connection attempts because it never received the CONNECT_IND.  

Thanks,

Tim W.

Yes, your understanding is correct. Perhaps you could try testing with a coax cable to rule out interference. You should still be able to use the sniffer either by using a splitter or maybe placing it very close to the devices.

Hi Tim C., I don't have any update at this time.  The environment where this occurs and was captured was in another location and I cannot reproduce it locally.  In several of the cases, it does appear that the device did not see the connect indication (obviously the sniffer did), but it is not clear why since we don't have synced logs for the peripheral side.   I am not really sure where to go from here on this issue until I am able to reproduce either locally or travel to the location where they captured the initial logs and try to gather more information.

It would be good to get confirmation that the TI stack does use the first packet as the anchor event even if it has a CRC error since that was my original question. 

Thanks,

Tim W.

Hi Tim C., I have been working on trying to capture the CONNECT_IND issue with additional details.   This time I also logged the peripheral device side (running TI SDK 3.1) with time synchronized between the sniffer and the device.   What I see is that the central sends a CONNECT_IND and then sends a LL_FEATURE_REQ as the anchor point.   The logs from the device show that it failed to establish the link (0x3e) error which tells me it did see the CONNECT_IND, but didn't obtain sync with the central.   The central does another connection attempt which is then successful.  In this case, I didn't see any reason why we were unable to establish the link as the timing from the central seemed correct with regard to the transmit window in the CONNECT_IND PDU and the packet passed the CRC.   I bookmarked the relevant event in the sniffer capture to make it easier to sync the time with the log below.

Thanks in advance,

Tim W.

Here is the peripheral device log running the 3.1 SDK with the relevant events in bold.  

[2019-06-04 10:43:50.866] 1122.227 0x20001bbc: ***HCI_COMMAND_STATUS_EVENT_CODE: 0x406:0x0
[2019-06-04 10:43:50.881] 1122.254 0x20001bbc: *BLE Disconnected: 0x16*
[2019-06-04 10:43:50.912] 1122.269 0x20001bbc: *Adv start*
[2019-06-04 10:43:50.912] 1122.273 0x20001bbc: ***Setting Tx Power to 7
[2019-06-04 10:43:51.136] 1122.505 0x20001c5c: Battery voltage: 2517 mV
[2019-06-04 10:43:51.312] 1122.686 0x20001bbc: ***HCI_LE_EVENT_CODE 0x14
[2019-06-04 10:43:51.352] 1122.691 0x20001bbc: *Adv stopped*
[2019-06-04 10:43:51.352] 1122.695 0x20001bbc: *BLE Connected*
[2019-06-04 10:43:51.352] 1122.699 0x20001bbc: Peer Addr: 0x3E1C4E7A2222, Type: 0
[2019-06-04 10:43:51.352] 1122.705 0x20001bbc: Good Peer address!
[2019-06-04 10:43:51.352] 1122.709 0x20001bbc: ***Setting Tx Power to 7
[2019-06-04 10:43:51.352] 1122.714 0x20001bbc: DTC Queue Reset
[2019-06-04 10:43:51.544] 1122.922 0x20001bbc: *BLE Disconnected: 0x3e*
[2019-06-04 10:43:51.572] 1122.934 0x20001bbc: *Adv start*
[2019-06-04 10:43:51.572] 1122.937 0x20001bbc: ***Setting Tx Power to 7
[2019-06-04 10:43:51.876] 1123.250 0x20001bbc: ***HCI_LE_EVENT_CODE 0x14
[2019-06-04 10:43:51.876] 1123.254 0x20001bbc: *Adv stopped*
[2019-06-04 10:43:51.917] 1123.258 0x20001bbc: *BLE Connected*
[2019-06-04 10:43:51.917] 1123.263 0x20001bbc: Peer Addr: 0x3E1C4E7A2222, Type: 0

EP1 connection testing on SDK3.1 6_4.zip