Checksum 0 after DFU init packet transfer

[raindeer]

Hi!

Im trying to implement DFU but got stuck at sending the init packet. 

The problem seems to be that the the init data doesn't get transfered somehow, and the symptom is that the CRC32 and offset returned after the transfer is 0. 

Any idea how to debug this further?

The CRC should be nonzero regardless of what data I have transfered to the packet characteristic right? Or is there some validation of the init packet being done before the CRC is computed?

This is my debug log:

SelectCommand: 0
Start of init packet send
SelectCommand results CRC: 0
Received PRN set response: 60-02-01
Control point notif data: 60-01-01
Command object data: 01-01-87-00-00-00
Command object created result: 60-01-01
Start of data transfer flen: 135
Reading 20 bytes from file stream
Sent data: 12-84-01-0A-3E-08-01-12-3A-08-36-10-34-1A-02-8C-01-20-00-28
### CRC32 Step value, crc: 534647752 offset:20 size: 20 packetLocalNo:1
Reading 20 bytes from file stream
Sent data: 00-30-00-38-A0-C9-03-42-24-08-03-12-20-FF-B7-05-03-3D-3E-04
### CRC32 Step value, crc: 1757713094 offset:40 size: 20 packetLocalNo:2
Reading 20 bytes from file stream
Sent data: 94-4D-55-01-D7-9D-61-77-7A-38-D9-2B-CE-0C-0D-B8-EC-6E-6A-C9
### CRC32 Step value, crc: 3411050851 offset:60 size: 20 packetLocalNo:3
Reading 20 bytes from file stream
Sent data: 38-E5-26-6F-DB-48-00-10-00-1A-40-63-5D-94-C5-85-06-B2-6D-2E
### CRC32 Step value, crc: 2163882705 offset:80 size: 20 packetLocalNo:4
Reading 20 bytes from file stream
Sent data: 0E-D2-AA-3A-47-C3-1D-27-1C-53-A2-F1-80-C7-03-8E-AB-9E-85-FE
### CRC32 Step value, crc: 784168122 offset:100 size: 20 packetLocalNo:5
Reading 20 bytes from file stream
Sent data: 46-03-88-C0-59-25-5E-B4-57-86-ED-00-60-74-A8-08-AA-F1-7A-19
### CRC32 Step value, crc: 1327207369 offset:120 size: 20 packetLocalNo:6
Reading 15 bytes from file stream
Sent data: FD-32-02-C8-55-E4-79-E5-2B-54-4A-DA-0C-E9-BD
### CRC32 Step value, crc: 4151597504 offset:135 size: 15 packetLocalNo:7
End of data transfer
Begin read checksum (sending 03)
Control point notif data: 60-03-01-00-00-00-00-00-00-00-00
Check Sum Response 60-03-01-00-00-00-00-00-00-00-00
End read checksum
Checksum received (Offset = 0, CRC = 0)
CRC does not match!

nrf52832, SDK v12.3.0, iOS

[raindeer]

Still have not been able to figure this one out. It is as if no data is sent to the packet characteristic. But everything looks correct for the control point characteristic so cant understand how this could be the case. Ive looked at many other implementations and I seem to be doing the exact same thing..

[Hung Bui]

Hi Raindeer, 

Could you give us more information on: 

- What do you mean by implement DFU ? Are you using our IOS-Pods-DFU-Library ? 

- Can you use the nRFConnect or NRFToolbox app to do DFU of the same DFU package .zip file you used ? 

- I'm not very familiar with the log you sent, from which side did you capture the log (phone or nRF5 ) ? 

- Could you let me know where exactly in this sequence chart you have the issue ? 

[raindeer]

Hi!

Sorry for not being clear. Im implementing DFU in Xamarin (C#) using the ACR BLE lib (https://github.com/aritchie/bluetoothle)

I can use nRFConnect and also other implementations to do the DFU. So the problem is not on the device side.

The log is from my implementation running on an iPhone.

If followed the chart you link. 
- I create the Command object with size 135 (01-01-87-00-00-00). Get 06-01-01 back as a notification.
- Transfer data to the packet characteristic in 20 bytes packets (WriteWithoutResponse)
- Then send 03 to get the checksum and get 60-03-01-00-00-00-00-00-00-00-00 (offset=0, CRC=0) back as if no data has been transfered.

If I ignore this problem and send Execute (04) then I get error code 08 back (Operation not permitted).

Somehow my data gets ignored. One question is this: if I send random data to the Command object and send 03 I still should get the CRC back, right? There is no validation of the init packet done before I actually execute it?

Thanks

[Hung Bui]

Hi Raindeer, 

There must be something wrong here. CRC must be calculated, unless there was no data received. I suspect somethign wrong with the write without response. 

Could you capture a sniffer trace ? If we can compare what you send and what our DFU library sends and find the difference. 

[raindeer]

Realized the problem is a bug in the underlying ble lib and caused by this: https://github.com/aritchie/bluetoothle/issues/257