Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • Hi,

    I do not quite understand what you are seeing here. The bootloader either

    • reads in the bootloader settings page that there is an applicaiton, reads the alleged application from flash and calculates the CRC, and if it matches the application CRC stored in the bootloader settings file it starts the application

    or, if the above fails,

    • enters DFU mode.

    If you can not get the device into bootloader mode again then that suggests that you have actually jumped to the application, but that the application fails. Have you tested the application by programming it directly with a programmer? In order to test it together with the bootloader you must also generate the bootloader settings file using nrfutil. Then you should also be able to run a debug session for the application.

    I see from the make target that you use --debug-mode and that there is no application version (only application version string). Are you using the debug version of the bootloader?

    I would like to get the bootloader hex file and the DFU zip file in order to reproduce, or flash dumps from before and after the upgrade ("nrfutil --readcode filename.hex" for dumping the nRF flash contents to a hex file.) If you do not want to share that here on the open forum then we can make the thread private first or you can create a private ticket and refer to this thread.

    Regards,
    Terje

Reply Children
No Data
Related