Debugging DFU ("Remote DFU operation failed")

RE: Debugging DFU ("Remote DFU operation failed")

Hauser — Mon, 18 Jul 2016 08:36:41 GMT

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.

RE: Debugging DFU ("Remote DFU operation failed")

testy — Wed, 23 Mar 2016 19:46:10 GMT

Really never ?

RE: Debugging DFU ("Remote DFU operation failed")

meadocean — Wed, 23 Mar 2016 01:32:06 GMT

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.

RE: Debugging DFU ("Remote DFU operation failed")

Bruce — Sat, 09 Jan 2016 03:16:00 GMT

We ran into the same DFU problem if we program 0x10001080 (using nrfjprog.exe, not compiled in any image) with some value. Anyone knows the root cause of this error?

RE: Debugging DFU ("Remote DFU operation failed")

Vidar Berg — Thu, 22 Oct 2015 08:14:57 GMT

It shouldn't be a problem to use the UICR registers as long as you don't include it in the DFU image. However, if you do the image will be much too big because of byte padding (0x18000 - 0x10001000 ~ 256MB .bin), maybe the cause of the error you got(?) The UICR registers are also best suited for data that won't change for the lifetime of the device (serial number, revison, etc) since a complete chip erase (NVMC.ERASEALL) is needed to update an existing value. The app data region should be used for storing of configurable data.

RE: Debugging DFU ("Remote DFU operation failed")

Lee Daniel Crocker — Wed, 21 Oct 2015 21:00:31 GMT

Aha...found the problem. I was using UICR address 0x10001080 for a serial number in my app. When I left that unprogrammed, all is well. When I filled it in, DFU fails (presumably it's doing some sort of checksum of memory).

Isn't the UICR range 0x10001080...FF supposed to be mine, to use for my app? If so, why is Nordic software messing with it?

RE: Debugging DFU ("Remote DFU operation failed")

Lee Daniel Crocker — Wed, 21 Oct 2015 15:38:28 GMT

Thanks. Same failure, so it's probably not the packet format. I'll try to compile the original loader out of the box.

RE: Debugging DFU ("Remote DFU operation failed")

Vidar Berg — Wed, 21 Oct 2015 14:12:43 GMT

Hi, I would suggest to try with the dfu_test_app_hrm_s110.zip located here :\nRF51_SDK_8.1.0\examples\dfu\ble_dfu_send_hex\test_images_update\dfu_test_app_hrm_s110.zip" and see if you get the same result. Then try with the unmodified bootloader in the SDK and do DFU with the file above if it doesn't work. With this I guess you can narrow down the issue to the bootloader itself, or something with the central.