This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Detailed DFU Application Interface Documentation

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.

Parents
  • 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.

  • I have been reading through the bootloader section in infocenter and am still not clear on exactly what to do.

    Maybe I am looking in the wrong place. Just to be clear I am working on SDK 15.3.

    Most of the information I am finding looks to be from the device side and not the mobile app.

    Can you give me some specific pointers? It would be nice to have a detailed description of 1. send these bytes, 2. expect this response or 2, 3. Now send these bytes, etc.

  • I have 2 versions of my fw. The only difference is this internal version I have. One I have hard coded version 110 and the other is hard coded version 111.

    If I use the Nordic app to flash 110 in and then use my characteristic to get the version using my app I get 110. If I then flash in 111 using Nordic it changes to 111.

    If I use my own app to do it then the version doesn't change even though I don't get any errors.

  • Here is the last bit of interaction between my app and the device:

    04-06 09:01:55.880 16705-16726/? I/UnityBluetoothLE: Checksumming from 0 for 37852 bytes
    04-06 09:01:55.881 16705-16726/? I/UnityBluetoothLE: Data object sent (CRC = B9E9FA25).
    04-06 09:01:55.882 16705-16726/? I/UnityBluetoothLE: Sending Calculate Checksum command (Op Code = 3)
    04-06 09:01:55.929 16705-16726/? I/UnityBluetoothLE: control bytes received: 60-03-01-DC-93-00-00-25-FA-E9-B9
    04-06 09:01:55.929 16705-16726/? I/UnityBluetoothLE: Checksum received (Offset = 37852, CRC = B9E9FA25)
    04-06 09:01:55.929 16705-16726/? I/UnityBluetoothLE: Executing firmware packet (Op Code = 4)
    04-06 09:01:56.285 16705-16726/? I/UnityBluetoothLE: control bytes received: 60-04-01
    04-06 09:01:56.285 16705-16726/? I/UnityBluetoothLE: Bytes remaining in firmware: 0
    04-06 09:01:56.287 16705-16726/? I/UnityBluetoothLE: Firmware Sent
    04-06 09:01:56.560 16705-16758/? I/UnityBluetoothLE: onConnectionStateChange
    04-06 09:01:57.573 16705-16726/? I/UnityBluetoothLE: Scanning for MYDEVICE
    04-06 09:01:57.574 16705-16726/? I/UnityBluetoothLE: Using api21scan
    04-06 09:01:57.574 16705-16726/? I/UnityBluetoothLE: Scan mode: 1
    04-06 09:01:58.093 16705-16726/? I/UnityBluetoothLE: Found MYDEVICE

    As you can see the final checksum matches what I calculated. You can also see that I send the Op Code 4 and get back 60-04-01 which indicates success.

    The next thing that happens is the device disconnects as you can see from my debug message of onConnectionStateChange. I then start scanning and find my normal device name instead of MYDEVICE DFU like I see when in DFU bootloader mode.

    I am not sure where to go from here. Does anyone have any suggestions?

  • The only reason why this could happen is that you flash 111 on 111 and expect 110, or flash 110 on 110 and expect 111. Perhaps can help from the fw side, but from mobile side receiving success at the end with correct CRC should mean the DFU worked.

  • Not sure what to say. I know I have 2 different versions and verify that because the final checksum is different between the 2. When I flash the same files using your mobile app it works. I thought maybe there was some step I was missing maybe, but couldn't find anything else to do by reviewing the Android source code.

    What all gets compared and verified by the DFU system? If the checksum matches, what else might be not matching? Is there some other step I have to take?

    Currently I upload the Init file and that checksum matches then I execute it and get a good response.

    Then I upload the bin file and that checksum matches and execute each block and get no errors and on the last one the device reboots all on its own.

    Is there maybe another step I missed that I should have seen by looking at the source code?

  • Hi Tony,

    Sorry for the late reply. My advise is to test using the debug version of the bootloader, that way you will get the log output from the BL and that may help you find where it goes wrong.

    Run first a DFU with the nRF Connect appen, and then with your own app and compare the logs to see if there is any differences.

    And as it was said before, getting sucess in the last execute response should mean that the app will swap bank 1 with 0 and the DFU should have worked..

    BR,

    Marjeris

Reply
  • Hi Tony,

    Sorry for the late reply. My advise is to test using the debug version of the bootloader, that way you will get the log output from the BL and that may help you find where it goes wrong.

    Run first a DFU with the nRF Connect appen, and then with your own app and compare the logs to see if there is any differences.

    And as it was said before, getting sucess in the last execute response should mean that the app will swap bank 1 with 0 and the DFU should have worked..

    BR,

    Marjeris

Children
Related