OTA DFU Bootloader SDK6.1

Question

We've got devices that are out in the field which were built on SDK6.1 w/ 110 SoftDevice 7.1.0 on an nRF51822. 
 Went with the dual-banked solution as that was what was available at the time of development, but we've run up against the allowed codespace w/ the dual-banked solution. I've been able to get the Single Bank solution working, and am able to use it w/ nRF Toolbox to load our Application image, but have not been able to successfully use nRF Toolbox to update our existing dual-bank bootloader. 
 I've been referencing the Master Control Panel Init Packet Handling -- and used the nrfutil.exe in the latest Master Control Panel (3.10..) to generate a package (ZIP) -- but when I attempt to DFU, I get the following error: "Init packet with 2-byte CRC supported. Extended init packet found." 
 My understanding is that the 2-byte CRC is what was supported in the early SDK6.1 that we used. I'm (ideally) wanting to use the nrfutil.exe application to generate the appropriate package that is compatible with the dual-bank bootloader that exists on our devices in the field. 
 Any pointers would be greatly appreciated. 
 Thanks!
-Tim

Vidar Berg · Accepted Answer

Hi, 
 Unfortunately, the example bootloader is not able to change its start address. So the start address in new and old bootloader should be the same. The reason we don not support is that it would be harder if possible to make it as fail-safe as it is with the current implementation. 
 Would it be possible to reduce the size of your single bank bootloader so it can start at 0x3C000 in your case? That would be the preferred option. Otherwise it may be possible to work around it by using the SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET to change the interrupt forwarding address so the MBR does not forward program execution to the old address in UICR.BOOTLOADERADDR. Note that UICR registers cannot be updated at runtime since a full chip erase is required to erase them (NVMC.ERASEALL). 
 Also note that the new bootloader does not foresee the change in the bootloader memory map when going from dual bank to single bank, which causes the the "bootloader update complete" verification to fail. 
 Normal program flow when doing bootloader update: 
 
 When doing DFU of new bootloader the
old bootloader loads the new image to
swap and sets 
p_bootloader_settings->bank_1 == 
BANK_VALID_BOOT followed by a system
reset 
 Bootloader starts and 
bootloader_dfu_sd_in_progress() 
returns 'true' since BANK_VALID_BOOT
is set in bootloader settings. 
 in
bootloader_dfu_sd_update_continue()
the bootloader compares its own image
with the one in swap. If they are
different the old bootloader will
assume that the one in swap is a new
one. In this case it will be
different 
 The comparison will return false so
the bootlaoder runs the
dfu_bl_image_swap() call to replace
itself with the new one (swap is
handled in the MBR). 
 The MBR will start the new bootlaoder
once the copying is complete. 
 BANK_VALID_BOOT will still be set
when the new bootloader starts, but
this time the comparison in
bootloader_dfu_sd_update_continue()
will return success so the bootlaoder
will proceed to
bootloader_dfu_sd_update_finalize()
call and clear the BANK_VALID_BOOT
flag. 
 
 However, in your case you will likely see that the bootloader runs the verification starting from BANK_0 instead of the old BANK_1 address, hence causing the bootlaoder to replace itself with an empty image from BANK_0. The workaround is to perform comparison on both new and old address in the new bootloader and check if either returns true. If one of them is true it means that the bootloader should proceed to bootloader_dfu_sd_update_finalize(). Answered a similar case here . 
 The init packet requirement was added in SDK 7.0.0, and this is the format that nrfutil follows.

OTA DFU Bootloader SDK6.1

Top Replies