DFU Verification Failure from Custom App

RE: DFU Verification Failure from Custom App

Tony — Wed, 11 May 2022 18:00:08 GMT

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.

RE: DFU Verification Failure from Custom App

Tony — Wed, 11 May 2022 15:41:05 GMT

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.

RE: DFU Verification Failure from Custom App

Tony — Wed, 11 May 2022 14:55:49 GMT

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.

RE: DFU Verification Failure from Custom App

Einar Thorsrud — Wed, 11 May 2022 10:11:08 GMT

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.

RE: DFU Verification Failure from Custom App

Tony — Tue, 10 May 2022 20:01:51 GMT

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.

RE: DFU Verification Failure from Custom App

Tony — Tue, 10 May 2022 14:14:20 GMT

I am not even sure how to go about all of that. I would like to send you my DFU .zip file and log of my process. Maybe you will spot something that will help. How do I send you some private files?

RE: DFU Verification Failure from Custom App

Einar Thorsrud — Tue, 10 May 2022 13:32:39 GMT

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.

RE: DFU Verification Failure from Custom App

Tony — Mon, 09 May 2022 20:27:06 GMT

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?

RE: DFU Verification Failure from Custom App

Tony — Mon, 09 May 2022 19:07:42 GMT

This makes sense. I will try dumping the raw bytes as I send them and compare to the raw bytes contained in the .zip file and see if there is a diff.

Can you confirm that the blocks of 4096 bytes put together should match the raw .bin file in the .zip file that is the DFU bundle?

RE: DFU Verification Failure from Custom App

Einar Thorsrud — Fri, 29 Apr 2022 11:36:58 GMT

Hi Tony,

[quote user=""]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.[/quote]

This means that has been transferred to the nRF is corrupt, as the hash does not match the hash in the init packet.

[quote user=""]I then download the 107K binary data file in 4096 byte chunks. All chunk checksums match during the download.[/quote]

These are checksums generated by your, app so in itself that does not mean that there was no issue. I do not have any insight into your DFU master application, but my gut feeling would be that perhaps there is an issue with how you segment the image chunks before sending them? You could perhaps dump the flash memory of the nRF right before the execute operation using one of our working implantations and your implementation, and compare the two dumps. That would hopefully give some insight into where you should look.

Einar