DFU Verification Failure from Custom App

[Tony]

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.

[Tony]

Can you please send me the Init packet format specifically the hash for the .bin file and where I can find it? The only thing that makes sense is that my init packet is not getting sent correctly from my app or processed correctly. We have looked in the docs and they say to look in the bootloader example. We looked there and can't find the exact format being used to determine which bytes are the hash.  I would also like to privately send you our init packet file so you can help better.

[Einar Thorsrud]

Hi,

There is no real documentation for the init packet unfortunately (though you can get some hints on it and how it is built using Google's protocol buffer in Customizing the init packet), but it should not matter though. It is generated by nRF Util, and the DFU master only transports it, and then it is read by the bootloader.

The init packet (init command) is stored in the bootloader settings page (see nrf_dfu_settings_t), so by comparing the flash as suggested before you will see if there is an issue with the init packet as well as the other data you have transferred. This should more or less immediately tell you exactly where you need to look closer.

[Tony]

We are trying to get set up to actually debug the bootloader. We are running into some trouble. If we enable the logging so we can watch the output, the bootloader doesn't fit in the flash anymore.

We think it should be able to because we do have logging turned on for our APP and can see logging output from it.

Can you help us get the bootloader so that we can build with logging turned on? We build the bootloader from your standard example with very little change. We just need help setting up the build config or linker script or ???? to get it to output debug logging messages.

We will then try doing DFU using the nRF Connect app (which works) and then using our app and compare the debug output.

[Tony]

We figured out how to fit the bootloader in the flash. We moved it down in flash by 0x1000 and then increased the size by the same.

Now when we debug the bootloader it is stopping with an error on Stopped by Vector Catch. It is basically hard faulting.

We are erasing the app so it should in theory stay in the bootloader. We want to be able to debug the bootloader.

What are we doing wrong?

Nevermind. We changed from being just 0x1000 larger to being 64k instead of 32k. Turns out it must be on some kind of even boundary or something.

Now we are trying to figure out why the logging isn't showing up.

[Tony]

You can ignore all of this whole thread if you like. We found the problem. We found it after finally being able to get logging going in the bootloader.

We then ran the DFU using the nordic nRF Connect app. Then we took a log with ours.

For reasons related to how our app was doing things we found that we were only sending 178 bytes, but the nordic app was sending 180.

We got flash write failures when we only sent 178 bytes. I fixed that and now everything is working fine.

I never got any other errors to indicate this was the issue, however, so it would be nice if the bootloader or SDK would be able to either handle blocks != 180 bytes or give some error on the command channel that would have been caught indicating what was going on.