Neither a disconnect nor a timeout after a LL_TERMINATE_IND

[thomas]

Hi,

we have an issue, related to an older post, but we don't get the timeout outlined in that post.

Our setup: we use the nRF52832 with the S132 V4.0.2 in the peripheral role and a iPhone / Android app in the central role. During a stress test we are rapidly sending commands from the app to the nRF. After a while the app stops sending commands because of an error and sends a LL_TERMINATE_IND packet. That is what we're logging with a bluetooth sniffer.

Now the problem is, that we don't get either a event or notification from the softdevice, that the connection has been terminated. We set the supervision timeout but also doesn't occur.

Has anybody an idea why we don't get either a BLE_GAP_EVT_DISCONNECTED or a timeout event?

Kind regards, Thomas

[laran]

I am having similar problem on SDK 14.2, using s132_nrf52_5.0.0_sd and running the nrf52 in central mode, listening to a connection. The peripheral sends a LL_TERMINATE_IND, then starts re-advertise itself. the nrf52 never return from the device discovery unless I reset it. on reset it connects again, as expected. I would expect a timeout if the discovery does not complete in time, right?

[Susheel Nuguru]

Iaran, did you manage to find what the issue was in your case?

[laran]

No, unfortunately not. Did you stumble upon this same issue?

[Susheel Nuguru]

We have someone else claiming that they see similar issue. I thought you might have had a solution. 

But thanks for caring to reply :)

[laran]

At the time I concluded the issue was with the device discovery module. However, it may be some configuration I had not understood or missed, basically miss use. My plan was to move to a more recent SDK although never got to it. Do you think that may solve the issue?

[Susheel Nuguru]

I am not sure at this point, but we will try to debug the issue with their hardware to see if this is something caused by nRF BLE stack or if it is related to the peer timings.