DFU Bootloader uploading smaller App

[MM-MUC]

Hi,

we have a NRF52832 based project / product. We are using a DFU bootloader for application and SD update. The update is done from a master microcontroller using UART.

Our update packages are created using the Nordic Tools and uploaded to the master microcontroller via ftp. All that is working just fine. 

We just have one problem: If we update the application with a smaller file than the one that is installed, the update fails. The bootloader reports "nrf_dfu_validation: Hash verification failed."

It looks like the hash is generated over a larger area of flash than the size of the application itself. When the application that has been installed before is smaller there seems to be a rest of the old application in the flash memory and the hash generation fails.

What can be done to avoid this problem?

[Vidar Berg]

Hi,

I'm not aware of any known issues that could explain this. Some suggestions for troubleshooting this further:

1. Attach a debugger and read out the bootloader settings page at the end of flash and check if the application size (nrf_dfu_settings_t -> bank0 -> image_size)

2. Read out the app image from bank0 and compare it to the original binary to see if there are any discrepancies.

Please also let me know what SDK version your bootloader was based on, and what the exact size of the app image in the working and failing case.

Best regards,

Vidar

[MM-MUC]

Hi,

the debugger reports the correct image sizes. The code itself written to the flash is correct as well. Exactly the same image can be uploaded when there hasn't been a larger image installed before. As soon as I increase the application size by using some const arrays the image installs fine.

Please note that I am only using a single bank as my application might be too large for bank switching in the future.

The app sizes are 159138 and 159432 bytes. 

The bootloader is based on SDK 17.1.0.

Marcus

[Vidar Berg]

Hi Marcus,

I don't recall seeing any issues like this before. The hash function should accepts input of arbitrary length and handle any required padding internally.
The flash is also erased progressively in 0x1000 byte sectors as the image is received by the bootloader, so any data following the application should still be 0xFFFF (until you reach the next page aligned address). I still think it's worth reading out the flash as suggested initially. Then you can easily compare what is actually different in the working and  failing cases.

Reading flash with nrfutil

nrfutil device read --address 0x0 --bytes 0x80000 > flash_content.txt

With nrfjprog

nrfjprog --memrd 0x0 --n 0x80000 > flash_content.txt

[MM-MUC]

Hi Vidar,

I agree, as the flash is written in 4096 Byte pages it's really strange that this happens. 

Usually that won't even be a problem as the size of an application normally increases. I only came across the problem after removing some debug RTT_printfs.

I will try reading the flash later today and let you know what I can see.

Marcus

[MM-MUC]

Hi Vidar,

very strange, I just tested it again. Now after the initial flash was done with the short version of the file, everything is fine I can flash short and long files back and forth without any problems.

No idea what was happening before, when I initially installed (via nrfjprog) the file with the long application.

Marcus

[Vidar Berg]

Hi Marcus,

Thank you for the update. I'm afraid I can't think of any explanation for this either. Please update the ticket if you manage to reproduce this again and collect more debug more information.

Vidar

[MM-MUC]

Hi Vidar,

I tried to reproduce that behaviour today. However, in the meantime to much changed on the side of our master microcontroller and that code is no longer compatible with the bootloader. Rolling back all that would be to time consuming. Therefore I hope the problem was just an isolated incident.

Marcus