Hash of the received firmware image does not match the hash in the init packet

[Navin]

Hello,

I have implemented DFU using I2C by modifying the original nrf_dfu_serial_uart.c file. Also, on the master side I have added an I2C adapter class.

The communication seems to be fine between the master and slave. The firmware upgrade process is working as expected until the last block of the firmware image is received.

When the last block is received, the Master throws an error message saying: 

raise NordicSemiException('Extended Error 0x{:02X}: {}'.format(resp[3], data))
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x0C: The hash of the received firmware image does not match the hash in the init packet.

I expected it to work without any problems as I have not modified the core implementation. Only the transport layers have been changed.

Can you let me know what might be going wrong?

Logs: uart_log.txt8255.dfu_i2c.log

I have attached the two log files from UART and I2C for reference. Please see the logs, the checksum received for all the blocks are identical among I2C and SLIP(UART) implementations.

SDK - 15.3

SoftDevice: s132 v6.1.1

Example: Serial DFU Debug

Application: ble_uart_peripheral

Hardware: nRF52 DK

Best regards,

Navin

dfu_uart.log

[Einar Thorsrud]

I have not checked in detail, but from the log, it looks like the transferred data is identical. If that is the case, then it should work, as you write.

There is one typical issue when modifying the bootloader, which we should rule out. If you are using SES, the bootloader project in the SDK is misconfigured, and will not generate a build error if the image is up to two pages (8 kB) too large, overwriting MBR params and bootloader settings. In this case, you would see undefined behavior. Can you try to move the bootloader start address down with two pages and see if this changes anything? This is a long shot, but it is worth ruling out.

[Navin]

Hi Einar,

I will give it a try and update you on this.

[Navin]

Hi Einar,

Can you direct me regarding bootloader start address? Where can I find this in the settings (SES). By how much would you suggest me to change it?

The bootloader in DEBUG mode worked fine a few times, after I removed redundant for-loop-print statements. But now, again, the same problem is occuring.

[Einar Thorsrud]

Hi,

You need to edit the section placement macros of the project, which you find from Project -> Options..., then as shown in this screenshot:

First of all, you could reduce FLASH_PH_SIZE by 0x2000 to see if you get a linker error (and keep it reduced regardless). If you do, then this is (at least part) of the problem. Then you fix it by moving down the bootloader start address (FLASH_START) by 0x2000.

[Navin]

Hello Einar,

I reduced the FLASH_PH_SIZE by 0x2000, but that doesn't work too. The same code works in non-debug example, but fails at the CRC validation after receiving first block(4096 bytes).

Please see the image above about the error reported.

What can be done about this?

Please let me know!

Best regards,

Navin

[Einar Thorsrud]

Hi Navin,

I don't have an explanation for this, but it is interesting that you only see the issue with debug builds. Can you upload the complete project here so that I can have a look? You can also upload it in a private case and refer to this thread if you prefer that.