OTA DFU packet characteristic - writeWithoutResponse

[Gabriel Gabor]

Hi,

I'm writing a client which does the OTA DFU for the nRF52832 and I'm a bit confused why the packet characteristic has the writeWithoutResponse property (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.2%2Fbledfu_transport_bleservice.html&anchor=ota_spec_dfu_packet).

While in theory it makes sense, in practice some libraries are not waiting for any response that the packet arrived (https://github.com/noble/noble/blob/master/lib/hci-socket/gatt.js#L144) and the OTA DFU won't work as the CRC request will be sent too early.

What is the risk of changing the characteristic from the SDK to not have the `write_wo_resp` property? Would this be considered bad practice? Should I force the client to ignore this property for the OTA case?

Regards,

Gabriel

[Einar Thorsrud]

Hi,

This is not an issue we have seen before. Packets are in any case acknowledged on the link layer (and retransmitted if necessary), and the BLE device is not allowed to send packets out of order. Doing so is a violation of the BLE specification, so I would say that if this really happens, then it indicates a bug with the library you are using on the peer side.

I discussed this with one of the developers of the DFU bootloader, and there are a few points worth noting:

• We do not recommend making changes in the DFU protocol (to not have the `write_wo_resp` property) as it will break compatibility with the protocol we have defined. However, you can do it if you want, provided you also change the UUID.
• The DFU implementation in the SDK has been rigorously tested and verified to behave as expected. No modification should be required.
• Another option could be to use the Packet Receipt Notification (PRN) mechanism of the DFU protocol as flow control. This is intended to be used on platforms that are too fast for the DFU target to keep up. You could for example try to set this to 12. In that case, you will send 12 packets, then wait for a notification before you can send another 12, and so on.