BLE v1.4.2 Central Role - a problem establishing a 3-rd connection.

This could be many things, not necessarily a stack bug.
1. you need to ensure that there is enough time to scan between connection events. What is the connection interval, scan window, and scan duration you are using? You can output Tx / Rx debug signals to see when scanning and other radio activities are occurring using the HCI_EXT_ExtendRfRangeCmd().
2. Verify peripherals are advertising at time you expect them to be via sniffer capture. Or verify that you can see them from another scanner.
3. Verify connection request is being sent by central. Check return status of API.

Hi Tim,

1. The connection interval is 100 ms. The scan interval and  scan window are both 48 (30 ms). I copied hen the scan interval and scan window from project HIDAdvRemoteDongle. Scan duration is 500 ms, but my understanding it is applicable to the discovery scan only.

2. Yes, peripheral are advertising at all times. Central device is able to see them before connections are established and soon after last connection is terminated.

3. Call to GAPCentralRole_EstablishLink() returns SUCCESS all the time, but events GAP_DEVICE_INFO_EVENT become sporadic after first connection and vanish as soon as second connection is made.

Thanks,

Hello George,

For the purposes of reproducing this, does this happen with the "Central to Multiple Peripherals V1.4.2" example application on the TI BLE Wiki?

Best wishes

Hello JXS,

Yes I am able to reproduce the same behavior with the "Central to Multiple Peripherals V1.4.2" .

Two CC2541 keyfobs and one SmartRF05EB+CC2541EM loaded with SimpleBLEPeripheral.

Same test:

1. Three devices discovered and connected one by one.

2. Cycling the power on SmartRF05EB; waiting until connection on Central is terminated; selecting CC2541EM from the device list and connecting to it.

Message on LCD should change from Advertising to Connected when CC2541EM is connected.

Repeat step 2 observing the message on LCD. After several times LCD will freeze in Advertising mode.

Thanks.

Hi George,

Thanks for providing the setup details. We'll attempt to reproduce on our side. Due to the complex nature of the setup, it may take a little extra time.

Best wishes

Hi George,

Wanted to let you know that we were able to reproduce the bug, and we will continue to look into this issue.

I'll give you an update on our progress next week.

Hope you have a great weekend,

-Rebel

Hi George,

We're still looking into this issue; could you provide us with a sniffer capture of issue you're seeing? We would like to verify that we're seeing the same issue you are -

We appreciate you bringing this to our attention,

-Rebel

Hi,

I didn't have a need for the sniffer. The issue is easily reproducible on TI demo hardware and software.

Let me know how to set up a sniffer and what details to capture, and I will be happy to assist.

Thanks,

George.

Hi George,

Do you have a CC2540EM? You could use that along with the TI Packet Sniffer to generate a sniffer log.

If you have another way to sniff over the air packets, that would help us verify that we are indeed seeing the same issue.

Thank you,

-Rebel

Hi,
Please, update me with the status.
My understanding, it is confirmed that TI was able to reproduce the bug using my instructions. Any TI BLE1.4 demo-boards running three simple_peripherals and one simple_central can be used. The simple_ central code has been modified by TI to allow three concurrent connections.

Thanks,
George.

Hi George,
It's still under investigation -
We would like a sniffer capture from you to verify that we're seeing the same issue - that would be greatly appreciated!
Thanks,
-Rebel

Hi Rebel,
I need guidance on how to set up a sniffer to capture what you need.
Thanks,
George.

You'll want to take a look at http://processors.wiki.ti.com/index.php/BLE_sniffer_guide

This will work with the:

• CC2540 USB Dongle
• CC2540EM + SmartRF05EB

-Rebel