No ATT communication possible anymore after 30 seconds (BLE_GATTC_EVT_TIMEOUT)

[Marko]

We have a problem on our test system:  it cannot communicate with our DUT on ATT level after 30 seconds.

Our DUT consists of a NRF52840 with SDK 16.0.0 and softdevice S113 version 7.0.1

The test system uses an ubuntu linux box with an USB BLE dongle (Startech BT1EDR4) running gattool (this test setup has been used in prior non-nRF52 BLE projects without a problem)

So everything works fine for 30 seconds, then after that no communication on ATT level is possible anymore, but the BLE connection remains. Bonding was succesfull and the link is encrypted.

On the DUT side we can see that after 30 seconds a BLE_GATTC_EVT_TIMEOUT event occurs after which no ATT communication is possible anymore. We do not understand why this event occurs though. When we setup a BLE connection with an Iphone or Android to our DUT this problem does not occur.

Any idea why we get this event? Should the test system perform some actions which are expected by the NRF52?

[bjorn-spockeli]

HI Marko, 

this is a GATT Client timeout so this indicates that the Startech dongle is not responding to a ATT request sent by the nRF52. My hunch would be that the nRF52840 is issuing a ATT MTU Update request using sd_ble_gattc_exchange_mtu_request and then Gattool and the starttech dongle is not responding to this, see the GATTC Timeout Message Sequence chart( its for the S132, but also valid for the S113). 

Would it be possible for you to capture a on-air trace of the communication between the nRF52 and the Startech dongle using our nRF Sniffer plugin in Wireshark and an additional nRF52 DK. Alternatively, if you have a Ellisys Bluetooth Protocol analyser or similar then that would of course be preferred. 

Best regards

Bjørn

[Marko]

Hi Bjorn, I was also suspecting something like this but I did not see anything on the air that indicates this.Wireshark log test system.pcapng

[bjorn-spockeli]

Hi Marko, 

Thanks for the on-air trace. So its after the Read by Type Requests (packets 900 and 901) that the nRF52840 stops responding and 30 seconds after this you get the BLE_GATTC_EVT_TIMEOUT event on the nRF52840 side?

Looking at the trace i see that the nRF initaties a connection parameter update, but according to the Peripheral Connection Parameter Update message sequence chart there appears to be missing a LL_CONNECTION_UPDATE_IND packet from the Startech dongle/gattool. So the SD is probably waiting for this and is hence ignoring the ATT requests. 

Best regards

Bjørn

[Marko]

Hi Bjorn,

No it's not 30 seconds after packet 900 it is about 30 seconds after the connection setup that we receive the BLE_GATTC_EVT_TIMEOUT (which is before packet 900). After the event is received no ATT communication is possible anymore and that is why no response is given on packet 900 and 901. I also suspected the connection parameter request at first, so we did a test without changing the connection parameters at all, but this did not help. We still got the same timeout after 30 seconds.

Best regards,

Marko

[Marko]

Hi Bjorn,

We have resolved the issue on the test system side. In the log I attached here you see an Central Address Resolution read request by the slave in packet 67. This packet is not answered by the master, hence the timeout 30 seconds later.

The test team has updated their ubuntu box from 14 to 18 and now the issue is resolved. Thanks for the time :-)

Best regards,

Marko