GATT Timeout on writing to buttonless dfu characteristic

[fhfs]

Hello Devzone,

We update our peripheral device(nrf52) with our gateway(nrf52840, central) using the DFU protocol. We have this working and the DFU update is successful when the device actually restarts to the bootloader.

However, when we start the DFU process by writing the instruction to restart to the bootloader, to the buttonless dfu characteristic. We sometimes get a gatt timeout (BLE_GATTC_EVT_TIMEOUT). We are subscribed to the buttonless dfu characteristic and we are using SDK 17.0.2.

Do you have any idea why we are getting this gatt timeout?

I reviewed the DFU logs from the nRF Connect app, and I've noticed a delay after the service discovery and subscribing to notifications. Do we need to add a delay there?

[Simonr]

Hi

Which of the devices is it that times out? What happens in the log of the other device when this timeout occurs? If you could provide a sniffer trace of the devices in the DFU that would be great so we could see exactly what is going on over the air. You can use any nRF52 family DK as a sniffer with our nRFSniffer firmware that's to be used with Wireshark.

Do you have any log between your devices that point to the notification subscribtion doesn't go through? To the best of my knowledge a delay like this shouldn't be required. HAve you tried implementing it to see if it decreases the chances of this timeout occurring?

Best regards,

Simon

[fhfs]

Thank you for your answer Simon.

• Which of the devices is it that times out?

Our gateway receives the timeout

• What happens in the log of the other device when this timeout occurs?

Both sides disconnect, no special error.

• If you could provide a sniffer trace of the devices in the DFU that would be great so we could see exactly what is going on over the air. You can use any nRF52 family DK as a sniffer with our nRFSniffer firmware that's to be used with Wireshark.

That will be hard. We use LESC encryption on our connections. Decrypting LESC is not supported with the current plugin, or is it?

• Do you have any log between your devices that point to the notification subscribtion doesn't go through? To the best of my knowledge a delay like this shouldn't be required. HAve you tried implementing it to see if it decreases the chances of this timeout occurring

I will set up another test to capture both logs and try adding the delay after the write response which enabled the indications.

[Simonr]

Hi

Thank you for answering my initial questions!

Sniffing a connection between paired devices is possible, and it's described how to that for connections that use LESC is described at the bottom of the Common Sniffing Actions guide here. 

Best regards,

Simon

[fhfs]

Do you know how to enable this debugging mode?
We are currently using LESC with OOB.

My best guess is setting the mode to just-works, but where do I put/set the public/private debug keys?

[fhfs]

I can indeed sniff LESC Just-Works connections with the nrf-sniffer and wireshark.
Daniel's method works perfectly