DFU Verification Failure from Custom App

I am writing my own DFU app for the nRF52832. I am using C# and .NET with Visual Studio.

For reasons I don't want to get into I can't use the Nordic SDK library with this project.

In a previous project I was able to write my own DFU process. I have copied that into this new project.

I have a .zip update file that contains the bootloader and app. This .zip file works fine when I use the nRF connect app and do the DFU process.

If I tried to use that same .zip file with my process it gets a EXT_ERROR_VERIFICATION_FAILED at the final step when I do the Execute operation.

I start by doing the Init download of 141 bytes. The checksum matches.

I then download the 107K binary data file in 4096 byte chunks. All chunk checksums match during the download.

At the end when I have transferred all the firmware I do the execute operation and the response is the extended error EXT_ERROR_VERIFICATION_FAILED.

Please give me some ideas about why this would happen.

Our bootloader and application are using SDK 15.3.0.

Parents
  • Well, I just wrote out each small 124 byte chunk that I am sending over BLE and which is matching the checksum that I do after sending a whole 4096 bytes and read that resulting file from the Android phone and compared it to the .bin file inside the .zip file I am using for DFU and the files match exactly.

    So what else could be the issue?

  • Hi,

    That is a good question. The only reason for getting EXT_ERROR_VERIFICATION_FAILED is if postvalidation fails because the firmware hash is not correct there. Perhaps you can use for instance nrfutil to perform a DFU, and abort the operation before activating, so that you can compare the flash content of the nRF with what you have when you use your DFU master implementation? There should be a difference there, and perhaps knowing what is different where would give some pointers.

Reply
  • Hi,

    That is a good question. The only reason for getting EXT_ERROR_VERIFICATION_FAILED is if postvalidation fails because the firmware hash is not correct there. Perhaps you can use for instance nrfutil to perform a DFU, and abort the operation before activating, so that you can compare the flash content of the nRF with what you have when you use your DFU master implementation? There should be a difference there, and perhaps knowing what is different where would give some pointers.

Children
No Data
Related