Losing Indication Confirmation from Central Device

[amarchand]

Hi,

We have encountered an issue where we are transferring data using our custom service back and forth from the nrf52811 to a remote test device and the radio becomes unresponsive. The test involves the remote device sending data to our service as an ATT_WRITE_REQ, and the nrf52811 responding with more data via ATT_HANDLE_VALUE_IND. These transactions are happening repeatedly during a single connection. Data is being buffered on the nrf52811 in both directions since the transfers are larger than the MTU. The test will continue to connect, request data from the nRF52811 peripheral, then disconnect repeatedly for as long as the devices can hold up.

In the attached trace, the last thing we see is that the nRF82811 send and indication at packet 15052, to which the remote device confirms, then sends an ATT_WRITE_REQ with a portion of the data, but the nRF52811 does not respond to this event with the ATT_WRITE_RESP. It appears that the nRF52811 application is waiting to see the indication confirmation, but it never does and gets stuck there. At this point the radio becomes completely unresponsive. We cannot communicate to it over the air nor via UART to our printer host device.

We are using SDK 16.0.

NoAttWriteRsp.cfa

[Edvin]

Thank you for the input, Daniel Veilleux!

Just to be completely sure, the nRF is the peripheral, and the one with address 00:07.4d:a8:e8:ed, right? (The device sending packet 15052). I am sorry if that is a stupid question, but I am not that familiar with the frontline sniffer. 

I agree with Daniel Veilleux, that 15052 is acked by the other device, but packet 15056 is not, which you can tell from the SN and NESN sequence. Are these the last packets over the air, or did you cut the trace there? I don't see any timestamps in the trace (but that may be because I don't know where they are written, or something weird with my setup), but I assume the connection has not timed out that quick. It should be able to handle some packet loss. 

I also received the log from the nRF which you sent to my colleague via email. It is one of the "parser service event" lines that you are missing? What are the numbers at the end of these lines?

So your application is still running at this point in time, where you lack the ATT_WRITE_REQ reply? Do you see this event on the nRF? And if so, when you reply, what function do you use to reply, and what does it return?

There doesn't appear to be an app_error, based on the log. You didn't remove that from the log or the logging module? Since you are using the nRF52811, I assume that you are using an SDK version that will log this automatically. 

What SDK and Softdevice version do you use?

Do you see any hardfault? (Processor stopping while debugging, and the callstack is pointing somewhere around 0x0a60)

If it is not too much to ask, is it possible to capture a sniffer trace using the nRF Sniffer? I am not saying it is better, but in Nordic we are a bit more familiar with it, and know where to look. 

Edit:

If the packets stop at the end of the sniffer trace. Do you see a disconnected event in any of the devices, the central or the peripheral? If so, what is the disconnect reason? If it is on the nRF, you can check it using:

NRF_LOG_INFO("disconnected, reason: 0x%02x", p_ble_evt->evt.gap_evt.params.disconnected.reason);

in the BLE_GAP_EVT_DISCONNECTED event in the ble_evt_handler().

If you see it on the other device (central), I guess they have their own SDK, if it is not a Nordic device.

Best regards,

Edvin

[amarchand]

We are using SDK 16 with Soft Device 113 version 7.0.1

Yes, the nRF peripheral is address 00:07.4d:a8:e8:ed.

The trace I sent is the entire over-the-air transaction. It was not stopped nor cut off. The "Parser Service Events" you see in the RTT ouput are the event we see in our custom service event handler, which are being output from its BLE event interrupt handler. They are output in hexadecimal. Nothing was removed from the logs. Everything we provided was the complete output from the radio and remote device. We do not get a hardfault at the point where we believe the application and/or soft device has crashed. 

We do not know if our application is running when the ATT_WRITE_REQ is missed, but it appears not to be, since the event never gets to the service interrupt handler. We do not see the disconnect event in the app since it appears to be hung by the time the remote device times out the connection. The other device is a Linux-based test application that is not using a Nordic radio.

We have attempted to use the nRF Sniffer in the past with varied success. We can try again if that would be mroe helpful to you.

I think I have answered all of your questions. If I have not or you need more information please let me know.

Best Regards,

Drew

[amarchand]

I have tried to use the nRF Sniffer but it can only decode the ATT packets on the single connection where it captures the LTK during pairing. Since our test script involves multiple connects and disconnects, we will need to continue using the Frontline snifffer.

Regards,

Drew