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.

[fhfs]

I have tried to recreate the GATT Timeout while the two devices are in debug mode with LESC level 2 and Debug Keys enabled. The GATT Timeout does not happen in the 20 times I've started the DFU.

It still does happen on our Release devices using LESC level 4. I don't see another way to pinpoint the problem with the GATT Timeout. Do you have any ideas?

[fhfs]

With nrf Sniffer version 4.0 we can use the SC LTK to sniff the connections