DFU - Bootloader fails to complete update with error 'Request to copy BL failed'

[rjdunn]

Hello!

We've written a custom bootloader (based off the secure_serial_dfu example), that uses SPI instead of serial communication. I can successfully update an Application using this custom bootloader, but when I attempt to update the bootloader itself, the process fails on the final 'Execute' step with the following logs: 

<debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 0
<debug> app: Verifying BL: Addr: 0x00073000, Src: 0x00041084, Len: 0x00008A70
<debug> app: Bootloader not verified, copying: Src: 0x00041084, Len: 0x00008A70
<error> app: Request to copy BL failed
<error> app: SD+BL: BL copy failed
<debug> app: Could not continue DFU operation: 0x00000004

Tracing back through the DFU modules, the error code (0x04) is ultimately being returned from sd_mbr_command (called by nrf_dfu_mbr_copy_bl()  in file nrf_dfu_mbr.c), and this code seems to correspond to NRF_ERROR_NO_MEM. Depending on the function, this error code is described as either of: 

-- NRF_ERROR_NO_MEM - If no parameter page is provided (see sds for more info).

-- NRF_ERROR_NO_MEM - if UICR.NRFFW[1] is not set (i.e. is 0xFFFFFFFF)

I’ve looked through the docs and forums, and there is limited info about this error. This page (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.sds%2Fdita%2Fsoftdevices%2Fs130%2Fmbr_bootloader%2Fmbr.html), describes a couple of ways to set the address of the “parameter page”. Specifically, I tried setting the address using “UICR.NRFFW[1] = … “, as suggested, and also by defining MBR_PARAM_ADDR  - neither of these changed the outcome. I see there are also some related variables in the linker file (unchanged from the secure_serial_dfu example), but it seems as though they are set correctly. 

Steps to reproduce the error:

- Build and Flash the custom SPI-DFU bootloader+Softdevice (5.1.1) -- [We are using IDAP-Link for flashing the NRF52 on our custom board]

- Make a small change (in logs) to the custom bootloader, and rebuild

- Use nrfutil to generate a ZIP package for this bootloader (specifying a higher bootloader-version). Here's the full nrfutil command: 

            nrfutil pkg generate --hw-version 52 --sd-req 0xA5 --key-file private.key --softdevice s132softdevice.hex --sd-id 0xA5 --bootloader nrf52832_bl.hex --bootloader-version 2 bootloader_v2.zip

- Unzip the package and concatenate the Init packet (.dat file) with the bootloader+softdevice image (.bin).

- Upload the concatenated binary to our custom board's Flash

- Master SPI running on custom board, then initializes the DFU process with the NRF52 chip. All steps succeed for the Init packet, and all succeed for the BL image except the final Execute command. This is where the error is displayed ("Request to copy BL failed")

-  Resetting the chip results in the original bootloader starting up, not the updated one. 

NOTE: While these steps include packaging the softdevice in the binary to use for the DFU update (creating a sd_bl.bin file), the procedure fails with the exact same error if I only update the bootloader (excluding the Softdevice from the update binary).

Environment Notes

- Custom board, using IDAP-Link to flash nrf52

- Dev Platform: Windows 10

- SDK 14.2

Any help/guidance you can provide for this issue would be very much appreciated! If there is any other information that would help to diagnose the cause of this problem, I would be happy to provide it. 

Thank you!

[Hung Bui]

Hi,

Could you let me know what exactly you did at this step "- Upload the concatenated binary to our custom board's Flash" ? 

So the binary image of the bootloader is not transferred via SPI ?

Do you transfer the init data ? 

I assume that you has made quite a significant change in the bootloader ?

We would need to have a look at your code to figure out what could be wrong here. 

But have you made sure you written to NRF_UICR_MBR_PARAMS_PAGE_ADDRESS (UICR.NRFFW[1]) the address for MBR parameter ? NRF_MBR_PARAMS_PAGE_ADDRESS by default at 0x7E000. This value need to be written to NRF_UICR_MBR_PARAMS_PAGE_ADDRESS . If you use other address you need to write that into the UICR. 

The address of the bootloader need to be written in NRF_UICR_BOOTLOADER_START_ADDRESS as well. 

I attached is the snippet of the code in the MBR, most likely it's the NRF_UICR_MBR_PARAMS_PAGE_ADDRESS was not pointing to correct location. 

m_check_copy_bl_params wouldn't return NOMEM. 

[rjdunn]

Thanks for your reply!

For the step you are asking about ('Upload the concatenated binary to our custom board's Flash'), I'm using X-Modem to transfer a binary containing INIT_PACKET+BL_IMAGE to the NVM of the custom board. A task running on the host chip of the custom board then starts the DFU process. Next, via SPI, it transfers the Init Packet first, then the BL Image, to the NRF52. For each of these transfers the task runs through the sequence of operations defined here. 

The changes made to the secure_serial Bootloader were mostly related to SPI functionality, and removal of serial functionality. Otherwise, they are very similar.

With regard to NRF_UICR_MBR_PARAMS_PAGE_ADDRESS, I see that in the file dfu_settings.c, the variable 'm_uicr_mbr_params_page_address' is set to NRF_MBR_PARAMS_PAGE_ADDRESS which is 0x7E000, Also I've confirmed that this address is still 0x7E000 during runtime, by printing it when the error occurs. Same for the start-address of the bootloader (NRF_UICR_BOOTLOADER_START_ADDRESS).

I may be mistaken but is the linker file responsible for writing the correct values to these addresses? I have attached my linker file here, as perhaps there is an issue with it that I'm not aware of. Again, it is the same file as that used in the secure_serial_dfu example.

Do you know if it is required to build the bootloader settings.hex and concat it with the BL for the DFU of the BL to work? I haven't seen this specified anywhere, but just wondering if this is the missing piece. 

Lastly, which file is the code snippet you posted in? I have searched the entire SDK for the vars 'm_check_copy_bl_params', and 'EMPTY_FLASH_BITMAP', and they cannot be found.. 

Thanks again for your help

secure_dfu_serial_gcc_nrf52.ld

[Anne van Rossum]

What's the purpose of NRF_MBR_PARAMS_PAGE_ADDRESS if it needs to be set in UICR anyway?

[Hung Bui]

In new softdevice (v6.1.1) we has updated the MBR so it will use the NRF_MBR_PARAMS_PAGE_ADDRESS  to store the bootloader location and setting instead of UICR. But it's still backward compatible, it will check the UICR if the MBR param page is empty.