Dual Bank DFU CRC computation failed *after* copy to bank 0

[Bart Cerneels]

I'm building a custom system based on the NRF52832 and S132 SoftDevice with SDK 14.2.0.

Our secure bootloader (bonded) is based on  examples/dfu/bootloader_secure_dfu. It's button handling is removed (no buttons) and more debug is added.

During a DFU of an application only package the data is successfully transferred to bank 1. The DFU controller requests a CRC at some point and I can see it's value on RTT output of response_crc_cmd_send().

Then after reset, the valid image is copied to bank 0 in nrf_dfu_app_continue().

After the copy is complete the CRC is calculated and compared with a stored value in dfu_settings. The calculated CRC matches the one send to the controller before boot.
The comparison fails and this leaves bank 0 invalid.

We don't have any input, thus no way to force the bootloader into DFU again. Our device is bricked.

I've been trying to debug this but lack understanding. For instance: what is the source of the CRC value in the dfu_settings?

I'm generating the DFU image using nrfutil version 3.5.0 with the following make target:

(OUTPUT_DIRECTORY)/$(PROJECT_NAME)-$(GIT_VERSION).zip: $(OUTPUT_DIRECTORY)/$(PROJECT_NAME).hex
    nrfutil pkg generate  --debug-mode \
        --application $(OUTPUT_DIRECTORY)/$(PROJECT_NAME).hex \
        --application-version-string $(GIT_VERSION_CLEAN) \
        --hw-version 30000 \
        --sd-req 0x9D \
        --key-file "$(KEYFILE)" \

[tesc]

Hi,

I am sorry for the delay. We have been out-of-office due to Easter holidays.

Note that you may experience some trouble if you increase the size of the bootloader itself past the flash page boundary, so check that you have not done so.

The crc field of the nrf_dfu_settings_t structure is the crc of the rest of that structure itself. The crc of the bank image is in the nrf_dfu_bank_t structures, e.g. bank_0.image_crc and bank_1.image_crc.

In nrf_dfu_app_continue(), after copying the application is done, the crc of the copied data is checked and then written to bank_0.image_crc. That way, when the data has been copied over (from bank 1 to bank 0) the crc should be the correct one.

Perhaps you can do a diff between the original bootloader from the SDK and your version, to see if anything stands out?

Regards,
Terje

[Bart Cerneels]

I indeed had to increase the bootloader size. I included NRF_LOG_BACKEND_RTT and a bit more debugging. The dfu_request_handling() is copied directly from the 14.2.0 examples/dfu/dfu_req_handling with some debugging and a change of hardware version.

Could you explain why changing the bootloader location and size can cause the CRC issue I'm seeing?
I've found this ancient document explaining relocating the bootloader:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_memory_relocating.html
Is any of this info still valid? Is relocating bootloader still possible with non-modified libraries?