Debugging DFU ("Remote DFU operation failed")

[Lee Daniel Crocker]

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).

[Lee Daniel Crocker]

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?

[Vidar Berg]

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.