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)" \

[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?

[Bart Cerneels]

I just reduced our bootloader size to 24k using the value from the secure_dfu_ble_gcc_nrf52.ld

FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000

In fact, our ld is exactly the same.

Now that debugging is disabled it's difficult to know for sure but it reboots in DFU mode, so I'll assume the CRC check failed again.

I will try with my J-Link plus in monitor mode later, but have not gotten that to work yet, hence the need for print debugging.

[Bart Cerneels]

Is it possible the CRC calculation while receiving the DFU data and the one after the copy from bank1 to bank0 is using different sizes? It's difficult to trace with bootloader_settings. Could the 2nd CRC be using a value it got from the DFU init packet?

I believe this is generated by nrfutil, but perhaps there is something wrong there.

[tesc]

Hi,

It is hard to change bootloader size during DFU, mainly because the bootloader start address is written to a UICR register. Also because bank size and location calculations (for where to download and move firmware images to and from) depend on where the bootloader begins, so that extra care must be taken if changing bootloader size during DFU. While possible, it does require a lot of effort.

It is much easier to stick to the same bootloader size. That size may be larger than the one we provide with the SDK, as long as you set the project settings flash start and flash size values correctly. In addition, the BOOTLOADER_START_ADDR define should also get this value, and it should be written to UICR. This should happen automatically for the various toolchains, as the value is fetched from the project settings for flash, but double checking never hurts.

I suspect that you get two separate errors. One when adding debug (related to changed bootloader size), and one when not adding debug (hard to tell what happens there). I found your private thread and will look into the files that you provided there.

Regards,
Terje

[tyana]

Hello,

have you found a solution to this problem in the end?