RE: Problem jumping to application in serial DFU

Bert — Tue, 27 Jun 2017 16:22:04 GMT

After digging a bit deeper, I started considering the package itself, namely dfu_test_app_hrm_s132.zip. The docs state that after unwrapped, the manifest file can be viewed. This manifest contains the following JSON:

{
    "manifest": {
        "application": {
            "bin_file": "dfu_test_app_hrm_s132.bin",
            "dat_file": "dfu_test_app_hrm_s132.dat",
            "init_packet_data": {
                "application_version": 4294967295,
                "device_revision": 65535,
                "device_type": 65535,
                "firmware_crc16": 37832,
                "softdevice_req": [
                    121
                ]
            }
        },
        "dfu_version": 0.5
    }
}

The attribute of interest here is sotfdevice_req. I found a mapping on the forum, which connects softdevice FWID to versions. In this case, dfu_test_app_hrm_s132 requires softdevice id 121, which maps to 0x0079. With that said, prior to uploading over DFU, I checked what the FWID was for the softdevice that ships with SDK11:

$ nrfjprog --memrd 0x300C
0x0000300C: FFFF0081

Note that the versions do not match. Long story short, the SDK ships with S132 v2.0.0 but that test hex file was compiled against S132 v2.0.0-7.alpha. After verifying this, I ran a simple test, compiling the ble_blinky example against S132v2, and requiring that particular softdevice during package generation:

nrfutil dfu genpkg --application blinky.hex --sd-req 0x81 blinky.zip

And uploaded

nrfutil dfu serial --package blinky.zip --port /dev/ttyS3 --baudrate 38400

Worked like a charm!

This is not an issue with Nordic per say, as those test files probably aren't maintained. It was more of an oversight on my end as I should have created my own hex opposed to using the sample hex in hci_dfu_send_hex.

Anyway, hopefully this will help someone else down the road. Maybe someone from Nordic can verify the findings as a sanity check.