Strange BLE Connection Behavior (no response to host packets) while using timeslot API

[swlnk]

Device: nRF52833

Board: nRF52833DK

SDK: 16.0.0

Soft Device: S140 7.0.1

IDE: SES for ARM v5.34a (64-bit) - Nordic Edition

Description of Issue:

I'm using the radio timeslot API to run a proprietary stack concurrently with BLE. For the most part everything is working as expected while advertising, but I'm seeing something very strange after I establish a connection (in the peripheral role).

What I'm seeing is this: I can establish a connection successfully, and the connection is able to stay maintained. I can see using an Ellisys sniffer that the link layer connection is stable, and there are empty packets going back and forth as expected. But I'm not seeing any packets containing any kind of host stack (e.g. L2CAP, ATT, etc) payload that are sent from my device. For example, if I use an nRF52 USB dongle as the central, I can see that the dongle sends an ATT Read By Group Type Request immediately upon connection, just as you would expect, but then there is no response from the peripheral. 

But then here's where things get even weirder: when I tried connecting with an iPhone (using LightBlue), I can see the connection get established, and I can see the iPhone send several LL control packets (e.g. LLCP version exchange, feature exchange, PHY symbol rate change to 2Mbps, LL Data Length Update) as it normally does upon connection. The peripheral properly responds to these requests, and even changes its PHY to 2Mbps correctly. But when the phone sends an ATT Exchange MTU Request, there is no response from the peripheral. The phone eventually drops the connection (probably due to an GATT timeout).

In my code I can see that events due to the LLCP packets are generated (e.g. I can see BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST events occur when the request comes in), but I don't see any events related to ATT (e.g. BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST) occur.

So to summarize, something that I'm doing that relates to the timeslot requests is causing the soft device to get into a state where it can only handle LLCP packets, but where it cannot handle any packets that need to be processed at the host layers of the Bluetooth stack. If I start the timeslot session (by calling sd_radio_session_open) but then never actually request a timeslot (by calling sd_radio_request), then I don't see this issue occur, but if I request just a single timeslot at any point in time (even if it is before I establish the connection) then I see this bad behavior happen during a connection, even if I'm not requesting any timeslots while the connection is active.

Is there something that I could be doing in my code that is causing the soft device to no longer process ATT packets but that doesn't interfere with processing of LLCP packets?

[Hung Bui]

Hi Sandeep, 

Could you give more information about how you request and handle timeslot in your application ? 
Do you only request timeslot for a short period of time, periodically or you try to request and extend the timeslot as much as possible ? 

From what you described, I suspect that the application was staying in a high priority context /interrupt handler probably at APP_HIGH level. This causing the softdevice event to the application not being handled and results in what you described. 

The LL control packet is handled by the softdevice that's why you can see those packet are still served by the peripheral, but not those who need involvement from the application (for example accepting MTU request). 

Please double check how the softdevice event is handled in your application (nrf_sdh_evts_poll() call, usually called inside SD_EVT_IRQHandler() )

Have you tested with our timeslot example here ? 

[swlnk]

I will answer your questions, but would also like to share a sniffer capture with you to show you what's going on. Since I don't want to share my sniffer capture publicly, I'll create a private ticket and reference this case ID

[swlnk]

Update: I created a private ticket for this. The case ID is 268304. Thank you for your help here!