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

Debugging DFU ("Remote DFU operation failed")

I'm using SDK 8.1.0 (SoftDevice 7). I built a version of dual_bank_ble_s110. Installed both on a freshly erased pca10028. It comes up fine and sets the LED on. It's advertising as "DfuTarg".

I packaged my application into a ZIP file using pc-nrfutils. Specifically, "nrfutil dfu genpkg --application package.zip" Aeverything indicates success, and it produces a ZIP file with my .bin, a .dat, and a manifest.json. I copy that file to my tablet.

When I run nRF Toolbox on my tablet, I choose the file, then connect to DfuTarg, and press the upload button. It appears to begin. It says "Connecting", then "Starting DFU...", then "Remote DFU operation failed").

I've done this with both the pca10028 and my custom board, and with my Nexus 7 tablet and a Samsung Galaxy (I know the Nexus 7 is notorious for slow BLE).

This post:

devzone.nordicsemi.com/.../

implies that perhaps there's a newer init packet format?

If not that, I'm not sure where to begin debugging (I do have a facility for outputting debug messages from the bootloader if needed).

Parents
  • Haha... I've suffered the same pain. And I found that the 0x10001080 address started 4 bytes are used by nordic dfu for device type and revision check, please refer to following code: // First check to verify the image to be transfered matches the device type. // If no Device type is present in DFU_DEVICE_INFO then any image will be accepted. if ((DFU_DEVICE_INFO->device_type != DFU_DEVICE_TYPE_EMPTY) && (p_init_packet->device_type != DFU_DEVICE_INFO->device_type)) { return NRF_ERROR_INVALID_DATA; }

    // Second check to verify the image to be transfered matches the device revision. // If no Device revision is present in DFU_DEVICE_INFO then any image will be accepted. if ((DFU_DEVICE_INFO->device_rev != DFU_DEVICE_REVISION_EMPTY) && (p_init_packet->device_rev != DFU_DEVICE_INFO->device_rev)) { return NRF_ERROR_INVALID_DATA; }

    I think its a reserved bytes for dfu device type and revision check, but never mentioned any documention...

    The UICR customer reserved area after address 0x10001084 shoule be ok for real customer purpose using.

  • Hey together, the UICR_CUSTOMER_DEVICE_INFO_OFFSET has to be modified as it is described here.

    Otherwise the bootloader check conflicts with your custom content in the UICR.

Reply Children
No Data
Related