Update SD+BL+APP from SDK v13 to v14 via DFU Fails

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Wed, 23 Oct 2019 14:58:50 GMT

HI Manuel,

so you are updating from SDK v14.2.0 to SDK 15.3.0 and you are still not able to get the SD+BL update to go through successfully using a nrfutil version between v1.5.0 and v4.0.0?

If it complets, then can you try do debug the bootloader and see if you enter its main() function?

Bjørn

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

ManuelF — Tue, 15 Oct 2019 08:33:41 GMT

I checked again, I have version 14.2.0 installed, sorry I misread. I'm using nrfutil v5.1.0.

I now tried your fix, but it does not help.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Tue, 15 Oct 2019 08:17:18 GMT

HI Manuel,

since the way we generate DFU images have changed between SDK v12.x.x and SDK v15.3 you will have to generate a SD+BL image with nrfutil v1.5.0 as its the SDK v12 bootloader that receives this image. Then after the SD+BL update you need to generate a APP image using nrfutil v5.0.0 or later.

Best regards

Bjørn

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

ManuelF — Tue, 15 Oct 2019 08:03:30 GMT

bjorn-spockeli: I have SD+BL+APP from SDK v12.x.x installed and I now try to update to SDK 15.3. I created a zip with SD+BL+APP with following command:

nrfutil pkg generate --hw-version 52 --key-file private.key \
        --application-version 2 --application application.hex \
        --sd-req 0x9D,0xB7 --softdevice softdevice.hex --sd-id 0xB7 \
        --bootloader bootloader.hex --bootloader-version 2 \
        app_dfu_package.zip

I update with nrfutil dfu serial. Now the first step updating SoftDevice+Bootloader is successfull. But the second step updating the Application fails! Is it possible the I now have the same problem, because the softdevice size increased? nrfutil failed on "Set Packet Receipt Notification 0" => TypeError: 'NoneType' object is not iterable.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Mon, 27 May 2019 07:31:24 GMT

koniho: Yes, this issue has been fixed in SDK v15.x.x.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

koniho — Fri, 24 May 2019 13:59:34 GMT

Is this issue addressed in a general way in bootloader built on SDK v15.2.0? What about SDK v15.3.0 - since it looks like there are significant differences between 15.2.0 and 15.3.0.

Thanks

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Thu, 07 Dec 2017 11:17:21 GMT

@koniho: Yes, if you're updating to a newer SoftDevice that is larger than the SoftDevice present on the device with SDK v12.x.x or later, then you need to implement the fix mentioned above.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

koniho — Wed, 06 Dec 2017 19:59:46 GMT

Does this issue affect older SDK based bootloaders as well (i.e. v12.3.0)?

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Fri, 27 Oct 2017 13:41:12 GMT

@amy60024: Could you try using the nRF Connect app instead of the nRF Toolbox app?

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

Amy — Fri, 20 Oct 2017 13:42:48 GMT

Hi Bjorn, I use the non-debug example, thanks.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Fri, 20 Oct 2017 13:39:40 GMT

@amy60024: Which bootloader project did you use, the debug or non-debug example?

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

Amy — Fri, 20 Oct 2017 13:30:26 GMT

Hi Bjorn, I faced the same issue. And also modified the bootloader for SDK14.0.0. The different is that I want to update the SD+BL+APP from from SDK12.2.0 to SDK14.0.0. I create the SD+BL+APP zip file by using nrfutil as following command. "nrfutil pkg generate --application app.hex --application-version 2 --bootloader bootloader.hex --bootloader-version 2 --softdevice softdevice.hex --hw-version 52 --sd-req 0x9D,0x8C --sd-id 0x9D --key-file private_key.pem sd_bl_app_firmware_image.zip"

But got the error message "upload failed: UNKOWN (8202)"

I tried the command as following to create the file for updating from SDK14.0.0 to SDK14.0.0, it works well. "nrfutil pkg generate --application app.hex --application-version 2 --bootloader bootloader.hex --bootloader-version 2 --softdevice softdevice.hex --hw-version 52 --sd-req 0x9D --sd-id 0x9D --key-file private_key.pem sd_bl_app_firmware_image.zip"

I also tried updating from SDK12.2.0 to SDK12.2.0, it works fine as well.

Thanks for help.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Mon, 02 Oct 2017 11:35:05 GMT

@adrian: Yes, this solution is not generic and will only be valid for a DFU update from S132 v3.x.x. or S132 v4.x.x to S132 v5.0.0. A generic fix that will work for all SoftDevices will be included in the next SDK release.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

Adrian Eggenberger — Mon, 02 Oct 2017 11:26:48 GMT

Hi Bjorn

As far as I see this is not a generic solution, isn't it? The offset of 0x4000 is correct at the moment for the updated from S132 4.0.4 to S132 5.0.0, but it could be wrong in some other cases. Is there a bugfix to fix this issue in a general way?

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Mon, 25 Sep 2017 08:26:41 GMT

We've found an issue with the Secure Bootloader's bootloader copy routine ( nrf_dfu_bl_continue() in nrf_dfu_utils.c ) - the logic in this routine breaks when doing a combined softdevice and bootloader update and the new softdevice is of a different size compared to previous version.

After the old bootloader has been swapped with the new bootloader, the new bootloader will compare itself against the banked version to verify that the MBR performed the swap correctly. The start address of BANK1, where the bootloader image is stored, is equal to the end of the SoftDevice. However, due to the change in SoftDevice size, from 0x1F000 with S132 v4.0.2 to 0x23000 with the S132 v5.0.0, the new bootloader will use 0x23000 as the start address instead of the old at 0x1F000. This leads to the memory compare operation being performed with a 0x4000 offset, which will fail.

The workaround is to modify the nrf_dfu_bl_continue() in the SDK v14.0.0 bootloader to check both the new and the old Bank1 start addresses, i.e.

static uint32_t nrf_dfu_bl_continue(uint32_t src_addr, nrf_dfu_bank_t * p_bank)
{
    uint32_t       err_code      = NRF_SUCCESS;
    uint32_t       ret_val      = NRF_SUCCESS;
    uint32_t const len          = (p_bank->image_size - s_dfu_settings.sd_size);
    uint32_t       old_src_addr;
    
    // if the update is a combination of BL + SD, offset with SD size to get BL start address
    src_addr += s_dfu_settings.sd_size;
    // Offset by 16K due to change in softdevice size. 0x1F000 -> 0x23000
    old_src_addr = src_addr - 0x4000;
    
    NRF_LOG_DEBUG("Verifying BL: Addr: 0x%08x, Src: 0x%08x, Len: 0x%08x", MAIN_APPLICATION_START_ADDR, src_addr, len);
    
    //Check new and old bank1 address to prevent new bootloader from repeating the swap with wrong src_addr
    err_code = nrf_dfu_mbr_compare((uint32_t*)BOOTLOADER_START_ADDR, (uint32_t*)old_src_addr, len);
        
    // If the bootloader is the same as the banked version, the copy is finished
    ret_val = nrf_dfu_mbr_compare((uint32_t*)BOOTLOADER_START_ADDR, (uint32_t*)src_addr, len);
    if (ret_val == NRF_SUCCESS || err_code == NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Bootloader was verified");

        // Invalidate bank, marking completion
        nrf_dfu_invalidate_bank(p_bank);

        // Upon successful completion, the callback function will be called and reset the device. If a valid app is present, it will launch.
        NRF_LOG_DEBUG("Writing settings and reseting device.");
        ret_val = nrf_dfu_settings_write(reset_device_callback);
    }
    else
    {
        NRF_LOG_DEBUG("Bootloader not verified, copying: Src: 0x%08x, Len: 0x%08x", src_addr, len);
        // Bootloader is different than the banked version. Continue copy
        // Note that if the SD and BL was combined, then the split point between them is in s_dfu_settings.sd_size
        ret_val = nrf_dfu_mbr_copy_bl((uint32_t*)src_addr, len);
        if (ret_val != NRF_SUCCESS)
        {
            NRF_LOG_ERROR("Request to copy BL failed");
        }
    }

    return ret_val;
}

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

tanekaf — Wed, 20 Sep 2017 16:38:44 GMT

Hi Bjorn. thank you for your reply. Success. Looks like is was missing "--sd-id 0x9d". Now, when the DFU app is used, it shows uploading part 1/2. After uploading part 1, the device disconnects and the app reports a failure. Using nRFgo Studio, the bootloader and softdevice are upgraded successfully. However, the application code does not upgrade. As an experiment, I programmed the board with SDKv14's softdevice and bootloader and used the same zip file to perform a DFU. DFU was successful. I suspect the issue is that SDKv13 used softdevice version 4.0.2 and SDKv14 uses softdevice version 5.0.0. Please advise.

RE: Update SD+BL+APP from SDK v13 to v14 via DFU Fails

bjorn-spockeli — Wed, 20 Sep 2017 13:33:19 GMT

You should be able to create a single SD+BL+ APP firmware image using nrfutil, i.e.

nrfutil --application app.hex --application-version 1 --bootloader bootloader.hex --bootloader-version 1 --softdevice softdevice.hex --hw-version 52 --sd-req 0x9D,0x98 --sd-id 0x9D --key-file private_key.pem sd_bl_app_firmware_image.zip