DFU OTA - first data chunk CRC/offset check consistenly fails

[Roiger]

Hi!
Some prerequisite info:

• We are using nrf52840 boards as our peripherals
• We are using v16.0.0 SDK
• We are using the s113 SoftDevice, more specifically s113_nrf52_7.0.1_softdevice.
• Since our central code is written in .NET Core, we use Windows.Devices.Bluetooth to take care of the PC side of the bluetooth.

Now onto my question:
Our peripherals are now Secure Buttonless DFU (without bonds) ready, and we can successfully do the DFU OTA process with .NET CORE code that I have written with the help of this link. The code follows the infographics in the link, and through events raised by listening to the notifications of the DFU control point, we successfully utilize the DFU protocol.

Our problem is that we almost consistenly (around 80-85%) fail upon the first data chunk CRC check- meaning, in the data portion of the DFU procedure shown in the infographic in the link above, I send the first data chunk of 4096 bytes, and then send a "Calculate CRC" command (opcode 3) to the Control point. Checking the received CRC and offset almost consistently returns an incorrect CRC or offset (expected an offset of 4096, usually receive one between 4010 and 4093). For all DFUs that fail at this point, resending the Create command (01 02 packet_size) on the first packet again always corrects this, and the DFU continues and finishes as wanted and expected, and the software seems functional.

A Step-by-Step Example in case my explanation was unclear:

1. Connect to a device with the "Buttonless DFU without bonds" Characteristic (UUID - 0x8EC90003-F315-4F60-9FB8-838830DAEA50)
2. Indicate the characteristic, and send the "Enter DFU command" (opcode 1, no data besides).
3. Reconnect to the "DfuTarg" device, with the original address + 1, and the DFU Control and Data Points.
4. Successfully do the entire Init packet part described in the link above.
5. Send a select command for the data part.
6. Send a create command for the first data chunk (4096 bytes).
7. Do data transfer of first chunk (no response as per the link)
8. Send "Calculate CRC" command, and the check fails (as previously explained- the offset is usually 4010-4093, as opposed to 4096).
9. Resend create + transfer of the first chunk.
10. The rest of the DFU continues and finished without glitches or errors.

What am I doing wrong? Is it a timing issue?

Thanks!

Roi

[Vidar Berg]

Hello,

It's interesting that it fails consistently, and only with the first data packet. I think it could be timing-related like you said. To narrow down the issue, would it make sense to try adding a small delay before and after sending the first data packet?

Best regards,

Vidar

[Roiger]

Hi Vidar,
Indeed when adding a sleep time before and after the first packet data transfer (300 and 200 ms respectively), The DFU no longer fails on the first send.

Thanks!

Roi