Detailed DFU Application Interface Documentation

Question

I need to implement DFU in a Unity3D application. I have tried to integrate the Android SDK library that you have on github. They are not integrating very well. 
 I have a lot of BLE experience and if I understand exactly the steps to implement sending a ZIP file payload over the DFU service and characteristics then I could probably do it without your library. This would also be good because I need this to work on iOS as well and being able to do it myself in C# code would be great because then I don't have to do native code for each. 
 The problem is that the documentation all assumes you are using the library you have provided. 
 Is there anything special that the library does? Does it actually break open the ZIP file and send the different parts over or does it just open a connection and send the ZIP file and have the firmware on the Nordic part do the work? If the previous then I would like to know the simple commands to implement that.

Turbo J · Accepted Answer

A detailed description of the DFU protocol can be found in the bootloader section of the infocenter. 
 Here is a very coarse overview: 
 The app opens the zip file and sends the meta information first (which the bootloader can choose to say "nope" to), then the binary firmware data in chunks, checked via CRC32. Once the last checksum is OK, the command to "execute" the update is sent.

Aleksander Nowakowski · Answer

The buttonless service is used to reboot your device into DFU bootloader mode. In that mode you device will only have DFU service and DFU Control Point and DFU Packet characteristics inside (except from Generic Attribute and Generic Access, of course). 
 How to use this service is explained here: Buttonless Secure DFU Service 
 For non-bonded devices, the bootloader will advertise with a different MAC address (+1). The phone needs to scan for it to connect to it. Our libraries take care of it automatically, but you need to make sure you connect to the proper device. Remember, that on iOS you don't have MAC address, so you can't compare it with the previous one. iOS DFU Library is using peripheralSelector , and the selection (starting from DFU from SDK 14) is using " Set advertisement name" feature (see the first link, command 0x02). 
 After you jumped to bootloader mode successfully, you need to check in what state your device is. You do this by setting the object to COMMAND. You will get the offset and CRC32 of the object. For fresh update both will be 0. If an update has started and may be resumed, they'll contain the proper values for you to compare (if cry doesn't match, or you don't want to resume, you always may start again by creating new COMMAND object). Then you need to follow the BLE Transport: Device Firmware Update process . 
 Regarding your question about the ZIP file. ZIP file contains 3 or 5 files. One is always the manifest.json, which specifies the names of 2 or 4 other files. In one ZIP file there may be an update for App only, or SoftDevice+Bootloader and App. Or any of them alone. The dat file is generated using nrfutil tool. The same tool may be used to read the content for the zip file, including decoding the dat files. The dat files are using Protobuf to encode the firmware size, type, hw type, required soft device(s), signature, crc, etc. They are to be sent prior to the firmware for validation. Bootloader may reject the firmware based on the init packet. 
 I would recommend first trying the bootloader using nRF Connect for Android or iOS. Check if your ZIP file is working. Then examine the log. All packets are logged there in a semi-human-readable way. This should give you more momentum. Good luck. 
 When you're done, and you'd like to contribute you project, we can always link to your implementation, just like we already have react-native and Flutter wrappers. 
 BR, Aleksander

Detailed DFU Application Interface Documentation

Top Replies