RE: SDK10 DFU Problems Freezing

Kevin — Mon, 10 Apr 2017 18:20:59 GMT

Thanks for the reply @jward. I can't find anywhere in SDK12 that has the .revision struct member. I think I must have a different problem with similar effect as you. I'll post a new question in Devzone. Thanks again.

RE: SDK10 DFU Problems Freezing

jward — Sat, 08 Apr 2017 16:20:46 GMT

Search your project for where you initialize the ble_dfu_init_t struct. The .revision struct member contains this value. It should be defined in two places: dfu_transport_ble.c for the bootloader and somewhere in your application when you setup the DFU service.

RE: SDK10 DFU Problems Freezing

Kevin — Thu, 06 Apr 2017 20:44:55 GMT

Where do you change this value? I've looked in main.c for both the app and the bootloader but can't find it. Thanks.

RE: SDK10 DFU Problems Freezing

jward — Tue, 04 Apr 2017 21:49:51 GMT

I solved the issue. For the Nordic tools other than Master Control panel (for some reason), the DFU revision characteristic is used to determine state information about the firmware. With SDK10 buttonless update, the DFU revision in the main application needs to be set to 0.1. The Nordic tools use this to tell that the device is operating in application mode rather than bootloader mode. In the bootloader, the revision needs to be set to specific values so the tools/libraries know how to communicate with the update service. This revision number is tied to the specific SDK version or DFU features you are using.

I was using this characteristic to store version information about my app. The main headache was that MCP wasn't using it for some reason. It made it hard to debug.

I found this comment about DFU revision in the iOS DFU library helpful:

0.1 - Device is in a mode that supports buttonless jump to the DFU Bootloader
0.5 - Device can handle DFU operation. Extended Init packet is required. Bond information is lost in the bootloader mode and after updating an app. Released in SDK 7.0.0.
0.6 - Bond information is kept in bootloader mode and may be kept after updating application (DFU Bootloader must be configured to preserve the bond information).
0.7 - The SHA-256 firmware hash is used in the Extended Init Packet instead of CRC-16. This feature is transparent for the DFU Service.
0.8 - The Extended Init Packet is signed using the private key. The bootloader, using the public key, is able to verify the content. Released in SDK 9.0.0 as experimental feature. Caution! The firmware type (Application, Bootloader, SoftDevice or SoftDevice+Bootloader) is not encrypted as it is not a part of the Extended Init Packet. A change in the protocol will be required to fix this issue.