CC2640: Link Established status 0x3A

Thank you Christin.

We are in advanced production phase, so it would not be very immediate to move to stack 2.2.1
The central role is played by an usb dongle (used by our custom pc application) on which we use the HostTest project and TI HCI protocol.
We log all the commands and events sent and received by our application on HCI protocol. The issue is frequent if one of the two peripheral device suddenly terminate connection with reason 0x08 (supervisor timeout, I am trying to understand why!!!). Soon after our dongle makes a new scan and tries to reconnect: in this case more than one attempt are necessary because on first attempts Link Established returns status 0x3A.

Is it a known issue of stack 2.1.0?

Furthermore, are stack 2.1.0 and 2.2.1 cross-compatible in connection and communication between central and peripheral devices?
I am considering the option to do a step by step upgrade, starting from the HostTest project on usb dongle. So, HostTest (central) with 2.2.1 would work properly with peripherals 2.1.0?

Thanks in advance for your support.

Best regards

Luca

Hi,

It will be easier for us to understand why the supervision timeout happened if you can provide the sniffer log.

I have not heard about this issue until now.

Yes, BLE stack 2.2.1 is backward compatible with BLE stack 2.1.

Hi Christin,

I am doing a deeper analisys of the problem and I will give you more details or logs as soon as possible.

Let me give you a brief introduction to our environment.
Our system can work with one or two peripheral devices connected to the dongle. The peripheral device is a virtual drawing and pointing device.
When the system works with 1 device, we can setup these connection parameters to the connected device, to minimize the power consuption:

connection interval: 100ms
slave latency: 0
supervisor timeout: 2000ms

When the system works with 2 devices, we need to use shorter connection interval in order to give a smooth visual feedback to the operator, so we setup:

connection interval: 10ms
slave latency: 10
supervisor timeout: 2000ms

So, when operating with two devices, we setup connection interval = 100ms while scanning with 0 devices connected, while connecting the first device and while scanning for the second device. As soon as both the devices are connected we switch to 10ms (sending command GAP_UpdateLinkParamReq to both connected devices), to ensure the required quick visual feedback. If one of the devices disconnects (discharged or out of range or any other cause), GAP_UpdateLinkParamReq is used to reset conn. interval to 100ms for the remained connected device, to be able to periodically scan and find the second device as soon as it is available again. And so on.

This conduct ensures that the operators can use one or two devices (as required for the application) without worring about connection management, and it works well.

But in some cases, and it is the main reason of my initial post, after a link termination with reason 0x08 (I must understand why), the first attempts of reconnection fail because Link Established returns status 0x3A. This causes delays and interruption of work to our costumers operators.

Now I am doing some bench test. And I will give you any details tomorrow.

Thanks for now.

Best regards,

Luca

Hi Christin,

I found out that the disconnection with reason 0x08 is due to devices that suddenly and randomly reset, I am investigating why.

My question now is: the connection attempts resulting in Link Established status 0x3A are related to master (HostTest) controller or slave (devices) controller that is busy? Which one?

Thanks for your support.

Best Regards

Luca

it's from the master.