nRF51 OTA DFU not working after successful image verification

[diode]

I am trying to do OTA DFU on nRF51-DK from a BLE dongle (CSR 4.0) and gatttool from BlueZ. The image is compiled from blinky_s110_pca10028 example (blinky_s110_pca10028.hex). I followed the SDK 8.0.0 documentation here (I used the most basic procedure without packet receipt notification), and how to build the init packet here. The init packet was

ffff ffff ffff ffff 0100 feff 5d1e

, in which 0x1e5d was the CRC checksum of the binary file blinky_s110_pca10028.bin. I have verified this bootloader was functional (passed the test documented here). And blinky_s110_pca10028 image was also functional when flashed with SWD to nRF51-DK. I have attached the log of OTA DFU using gatttool http://pastebin.com/urZtiE2e . You can see that everything before and including verification was successful because you can see notification message like

char-write-req 0x10 04 --listen

Notification handle = 0x0010 value: 10 04 01

However, after sending command

char-write-req 0x10 05

to activate and reset the chip, I still saw "DfuTarg" advertizing, meaning OTA DFU was not successful. What am I missing here?

[Hung Bui]

Hi Diode,

You can try to read out (using nrfjprog) the chip's binary to see if the image has been updated properly or not. If possible you can upload it (the bootloader hex file, the blinky hex and the readout hex file of your chip after you finish DFU) here so that I can have a look.

You can also debug the bootloader to see why it doesn't jump to your application. You can find information on how to change the bootloader configuration to support debugging here. If it's not easy to debug with Linux and gcc, you can try to sending information via UART for debugging.

[diode]

@HungBui I have used the command "nrfjprog --readcode filename.hex" to read out the image to hex files. You can find the hex before OTA here and after OTA here. A diff output shows they are not different. However, according to the log, the image verification is successful (returning request op code of 1). Also, I tried intentionally interrupt the OTA DFU in the middle, and read out the hex file after that. The file is also not different from the other two. What could happen in this process?