nRF52840 with SDK 15.2 running with BLE and Data Length Extension

[SebastianGutzwiller]

Hi all,

I observe a connection supervision timeout (HMI error code 0x08) in my Nordic firmware with certain Android smartphones (controller).

Additional info regarding GATT events: After the last connection parameter update and some GATT events the softdevice stops reporting BLE_GATTS_EVT_HVN_TX_COMPLETE and BLE_GATTS_EVT_WRITE.

After exchanging the MTU request in GATT the controller sends data length update requests over GAP with

• Max number of payload octets to receive of  251 bytes
• Max reception time of 2120 us
• Max number of payload octets to transmit of  135 bytes
• Max transmission time of 1192 us (BAD CASE) and 2120 us (GOOD CASE)

Any ideas?

[SebastianGutzwiller]

/cfs-file/__key/communityserver-discussions-components-files/4/ndk_5F00_s7_5F00_disc_5F00_dur_5F00_login2_5F00_filt.pcapng

Here is a Wireshark trace first of a good case & a bad case.

HTH Sebastian

[SebastianGutzwiller]

1) Open point: We need to check what Bluetooth event can be traced on those Android smartphones.

2) The trace was recorded with a firmware containing S140 v.6.1.1.

[SebastianGutzwiller]

I updated the SoftDevice to version 7.0.1 and still have the connection supervision timeouts in about 1 of 7 connections with some smartphones.

In those cases I can confirm that the SoftDevice called with sd_ble_gatts_hvx() is always returning NRF_SUCCESS and the SoftDevice stops sending BLE_GATTS_EVT_HVN_TX_COMPLETE filling up the transmit queue on the application side (variant #2 of https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.0.1%2Findex.html).

Can the transmission of the Handle Value Notification be prevented by events outside of the SoftDevice? Can one monitor that HVN transmission in more details?

[Amanda Hsieh]

Hi, 

SebastianGutzwiller said:

SoftDevice stops sending BLE_GATTS_EVT_HVN_TX_COMPLETE filling up the transmit queue on the application side

How many NRF_SUCCESS is returned by the sd_ble_gatts_hvx before the softdevice stops sending BLE_GATTS_EVT_HVN_TX_COMPLETE?

How do you know the softdevice stops sending  BLE_GATTS_EVT_HVN_TX_COMPLETE? Could you provide the debug log?

How big is your hvn_tx_queue_size ?

SebastianGutzwiller said:

variant #2 of https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.0.1%2Findex.html

I think you mean this GATTS Handle Value Notification. 

SebastianGutzwiller said:

Can one monitor that HVN transmission in more details?

The sd_ble_gatts_hvx can keep track of the available queue element count for notifications by following the procedure below:

• Store initial queue element count in a variable.
• Decrement the variable, which stores the currently available queue element count, by one when a call to this function returns NRF_SUCCESS.
• Increment the variable, which stores the current available queue element count, by the count variable in BLE_GATTS_EVT_HVN_TX_COMPLETE event.

 -Amanda H.

[SebastianGutzwiller]

/cfs-file/__key/communityserver-discussions-components-files/4/nordicapp_5F00_sdk16_5F00_dle_5F00_s7_5F00_connect_5F00_wal_5F00_4.log

That's the trace file logged with one good connection & one failed at the end.

[SebastianGutzwiller]

As you can see in the trace file it was about 13 times a successful sd_ble_gatts_hvx().

The hvn_tx_queue_size is 6.

The procedure for handling the transmit queue is implemented exactly as you described it.

[Amanda Hsieh]

Hi, 

  It seems to be related to the LL_CONNECTION_UPDATE_REQ. After the new connection interval should have taken effect, the nrf does not respond anymore.
It is maybe the master/phone packet is sent outside the the allowed window,i.e. not between instant+transmitWindowOffset and instant+transmitWindowOffset + transmitWindowSize. Those will stop transmission of the Handle Value Notification. Then, we go back to check log "ndk_s7_disc_dur_login2_filt" again, and find:

At event 71, the new connection parameters should have taken effect... but the master is not sending any packets at connection event 71.

Maybe the user could try to update the software on the phone. Maybe there is a software update pending for the phone. 

This log "ndk_s7_disc_dur_login2_filt" points to a problem with the phone. And if you only see the problem with certain phones, then that also supports that.

-Amanda H.

[SebastianGutzwiller]

Hi Amanda,

Thanks for the detailed explanation.

The actual project status is that this phone (it's actually my own and it is updated) is one of the first which shows that behaviour.

It is planned that we conduct broader DLE tests with the most used smartphones. Therefore it is important for us to understand exactly what is happening here.

You are talking about a connection event 71. I don't see it in the wireshark trace. Do you mean LE LL Instant 70? What packet should the master send at that event?

Cheers
Sebastian

[Amanda Hsieh]

Hi, 

If it doesn't disconnect, then you will have event71. Did you do a similar thing in the first part connection at frame #941? If so, you can take a look at its next event 72 what the master sent. 

--Amanda H.

[SebastianGutzwiller]

Hi,

Thanks, now I see what you meant.

Our actual workaround which works with that smartphone is that the slave don't send any GAP connection parameter update requests and accepts all from the master. With the drawback that the slave could run out of its current budget.

Cheers
Sebastian