CC2640R2F: TI CC2640 Sending Out Connection Indication Packet Too Late

Hi, 

Assigning an expert to comment.

Thanks,

Is there anyone from TI who can comment on this?

Hello Paul,

That is quite odd and in fact seems impossible if you ask me.

Are you sure the connection indication (CONNECT_IND) is not following a later advertisement packet  (ADV_IND) than the one you assume?

Please upload a sniffer trace, although keep in mind that it is possible for the sniffer to miss an ADV_IND packet.

What happens if you use a CC2640 Launchpad in peripheral mode as the DUT?

Hi Eirik

could you provide me a box location for me to upload the trace? There are concerns on our part about uploading the trace for general view

Paul

Hi Eirik

I think Joe George shared a box location for you which contained the trace. Were you able to access that?

Hello Paul,

I got the log and had a look.There is many devices and a lot going on. At first glance it seems like the BLE sniffer could actually be missing the initial packets and therefore misinterpret the delay (T_IFS). In this case the  Connection Indication (CONNECT_IND) packet may be missed by the peripheral as well.

Are you able to reproduce this with fewer devices transmitting traffic over the air?

Hi Eirik

in a completely isolated environment I can successfully connect and disconnect 5000 times without issue. However our concern in not in this environment but in noisy environments.

Out concern is that the TI dongle is "busy" doing other things to send out the CONNECTION Indication packet.

From our analysis it appears the device is operating properly and the dongle is simply not sending out the CIP in a timely fashion. Is there a way to instrument our Central Dongle in order to give us more data to solve the issue? We are using a high end Ellisys sniffer and I grant you that packets could be missed by the sniffer but we feel the trace provided matches the problem we are seeing.

We are willing to run any debug code you think is needed to solve this issue but with the knowledge that our device still need to connect in somewhat noisy environments

Hello Paul,

When you say dongle are you referring to the Launchpad?

In general on a higher level there can be issues if either the RTOS stack task does not have the highest priority or if it is blocked from execution on the CM3 core for a prolonged time. But the CONNECT_IND  packet which is part of PHY is handled by a separate Radio Core processor and part of the CMD_BLE_INITIATOR command which will first scan and then transmit connection indication automatically on the received wanted ADV_IND packet.

The best way I know of to verify T_ifs (timing) is to expose the LNA enable and PA enable output signals on your DUT and Initiator and correlate that with what you observe in the sniffer:

dev.ti.com/.../debugging-index.html

Hi Eirik

let me digest what you are saying

refer to the "Debugging RF Output" chapter in the link above.

The CMD_BLE_INITIATOR command is explained in the TRM( CC13x0, CC26x0 SimpleLink™ Wireless MCU Technical Reference Manual (Rev. H) )section 

23.6.4.6 Initiator Command.

In short, the CONNECT_IND timing (after receiving ADV_IND) should not be affected due to any activity on the application processor (CM3) as it is running on its own RF Core processor (ARM Cortex-M0, refer to Figure 1-1. CC26x0 and CC13x0 Block Diagram in the TRM). 

Hi Eirik

I promise you we are still looking at this issue.

What we have in our code is 2 defines TASKs. We have these tasks defined with Priorities 1 & 3. Do you think that task we have set at priority 3 could interfere with the TI RTOS()??  I suppose we could change it to 2 and re-test

I do want to keep this issue open as we investigate these suggestions from you

Paul

Hi Eirik

a couple of things. We have instrumented the LEDs as suggested. However we aren't really sure what we should for here. Suggestions?

Also concerns the CM3 core getting blocked. What types of events might we be calling which cause cause the CM3 to be blocked?

One additional point is that occasionally I do see GPIO6 being held high for a very lengthy time (70 milliseconds). I find this a little unusual

Also we did change the priority of one of our tasks from 1 to 2 but that didn't make an appreciable difference

Hello Paul,

I would sniff these signals (LNA enable (RX), PA enable (TX)) on both the Initiator (Master) and the advertiser (Slave/DUT) on the same logic analyzer to make sure the timeline match for the 2 devices. Then you can compare/correlate these signals with the ADV_IND/CONNECT_IND.

DIO6 is mapped to LNA enable(RX) and can be active for prolonged periods as it is simply scanning until it receives the wanted ADV_IND packet.