CC2640R2F: Connection parameters update issue

Can you elaborate on "it won't respond to any further next updates from the Android device and then the link goes down"? How does the link terminate?

It would be best if you could just attach the full sniffer capture.

Hello Tim,

As you can see in the figure, the Master sends a LL_CONNECTION_PARAM_REQ, and the slave does not respond.

Regarding the "link goes down", what happens is that the Slave and Master just stop sending empty packets (the connection is dropped).

Again, this only happens when the Android device (Master) sends the LL_REJECT_EXT_IND. If I use an Android device that does not send this, the link is maintained like expected.
Why is this happening ? Is that a known problem of this SDK ?

Can I send you the sniffer logs by private message ?

Best Regards,
Walter Pires

Can you just attach a screenshot of the part where the connection drops?

Hi Tim,

Here it is:

Best Regards,

Walter Pires

Ok so the master is terminating the connection because of the 40 second link layer control procedure timeout after the slave never responds to the LL_CONNECTION_PARAM_REQ. The strange thing is that the slave successfully maintains the connection until this timeout occurs. I would expect it to have crashed.

I don't see how to debug this without instrumenting the stack so I may need to try to reproduce this.
Is this repeatable? That is, does the slave not respond to the LL_CONNECTION_PARAM_REQ every time the the master sends the Reject?

Also, can you profile the heap to see if there are any failures? See the "Debugging Common Heap Issues" of the software developer's guide; software-dl.ti.com/.../ble-common_heap.html

Sorry I didn't mean to click TI thinks resolved.

I don't have an Android phone but I'll be working on replicating by this by forcing a reject_ind from a TI master.

Hi. Which stack in the simplelink_cc2640r2_sdk_1_35_00_33 installer are you using? BLE-Stack v3.0.1 or BLE5-Stack v1.00.00.33?

Hi Tim,

I'm using BLE-Stack v3.0.1. 

Best Regards,

Walter Pires

Can you verify whether or not you are receiving a GAP_UPDATE_LINK_PARAM_REQ_EVENT in gapRole_processGAPMsg() in peripheral.c? You should be receiving this on both the initial param update request (where the master sends the reject) and on the second one (where the slave never responds).

Hi Tim,

I already verified this, and the first connection parameters request (GAP_UPDATE_LINK_PARAM_REQ_EVENT) is received in gapRole_processGAPMsg(), but the second one is not received.

Best Regards,

Walter Pires 

Hi Tim,

Any news on this topic ? I really need your help on this point.

Best Regards,

Walter Pires

Sorry nothing to update yet; I haven't been able to replicate or had time to look into it. Hopefully I should have some time next week.

We are investigating a similar issue so hopefully that should solve this once completed.

As a workaround, you should be able to disable the LL_CONNECTION_PARAM_REQ feature (and thus force LL_UPDATE_INDICATION's). SimplePeripheral does this by default via not defining USE_LL_CONN_PARAM_UPDATE in simple_peripheral.c

Hello Tim,

That is not a option because the consumption will be much higher. I cannot have this type of consumption in my product.

Please see this with urgency, i really need this solved. The client is asking to get this solved in a short time.

Please analyse this and see a real solution to this problem, the solution you provided would only bring an additional problem.

Best regards,

Walter Pires

Hi, I don't actually think the current consumption would be higher. Presumably the Android master would use LL_CONNECTION_UPDATE_IND to update the connection instead of LL_CONNECTION_PARAM_REQ which would actually make for a quicker update since the slave doesn't have to send a LL_CONNECTION_PARAM_RSP.

In any case, it's just a workaround. The problem right now is that we still aren't able to reproduce this. I've replicated the exact master functionality from a TI master and everything works as expected.

What Android device is this showing up with?

Hello Tim,

The consumption is higher (near 1 mA), I already tested. This happens because the slave latency that the android uses with LL_CONNECTION_UPDATE_IND is 0. That's why I need to use the LL_CONNECTION_PARAM_REQ in order to ask for slave latency to be 50. Then the consumption decreases for the values that I want.

The device has Android 8.

Best Regards,

Walter Pires

The functionality changes based on the phone that is used. Can you please state exactly which phone you are using and I will try to find one?

Hello Tim,

I'm not using a phone. I'm using an Android Set-Top-Box.

Best regards,

Walter Pires

I do not have any Android Set-Top boxes (we would likely need the exact one anyway) so I still don't have any way to replicate this. You mentioned above that disabling LL_CONNECTION_PARAM_REQ was not acceptable because you need to update the parameters. Note that it should still possible to do this without LL_CONNECTION_PARAM_REQ by using the the L2CAP CONNECTION PARAMETER UPDATE REQUEST. Have you tried this? There shouldn't be any changes needed in the code besides disabling LL_CONNECTION_PARAM_REQ