DFU SDK6.1+SD7.1 to SDK1+SD8

[Dave_couling]

I'm trying to piece together how to be able to get this migration to work OTA via DFU. I was told by Nordic that all you need is to .zip SD8 + Boot(SDK10) and DFU both to update. However these seems to fail.

I followed a previous posts to create the zip using nrf.exe.

nrf.exe dfu genpkg sd8_and_boot.zip --bootloader sdk10_dfu_bootloader_xxaa.hex --softdevice s110_nrf51_8.0.0_softdevice.hex --application-version 0xffff --dev-revision 0xff --dev-type 0xff --sd-req 0xfffe

The SD update functions dfu_sd_image_swap() and dfu_sd_image_validate() don't seem to have any issues (no errors), but obviously my debugger loses track at dfu_bl_image_swap(). In bootloader_settings, it correctly tracks the sd_image_size=88344.

Inside dfu_sd_image_swap() I have the following values:

• sd_start 4096
• block_size 0xA800, 43008
• img _block_start 0x2B000, 176128
• sd_block_start 0x16000
• image_end 0x2B918, 178456

Inside dfu_sd_image_validate() I have the following setting values:

• sd_image_size 0x15918 88344 (correct for SD 8)
• sd_image_start 0x16000

I also noted that dfu_image_validate() fails because the m_image_crc != received_crc. However the entry in m_init_packet[3] does contain the correct CRC value. Is this a compatibility issue?

Is there anything I'm missing to be able to support this OTA migration?

Thanks for the help guys,

[Vidar Berg]

The update procedure in SDK 6.1.0 differs slightly from the bootlaoder in SDK 7 and later. Mainly that the extended init packet is not supported which causes the wrong crc value to be parsed from the init packet. So to update from this bootloader you will need to use a different distribution packet so nrftoolbox goes into "legacy" mode

Steps to create legacy distribution packet for Android (nrftoolbox v. 1.16.3):

Create a .zip folder with bootloader.hex and softdevice.hex.

Example : sd8sdk10_android.zip

Same for iOS (nrftoolbox v.3.0.1):

Use nrf.exe as you described, but edit the manifest and .dat (CRC = last 2 bytes) file so the init packet only contains the CRC value.

Eg., manifest.json:

{
    "manifest": {
        "dfu_version": 0.5,
        "softdevice_bootloader": {
            "bin_file": "sd_bl.bin",
            "bl_size": 13172,
            "dat_file": "sd_bl.dat",
            "init_packet_data": {
                 "firmware_crc16": 32149,
             },
            "sd_size": 88344
       }
   }
}

Example : sd8sdk10_ios2.zip

Also, you will need to do a minor change in the SDK 10.0.0 bootloader to keep the same bootloader settings format as SDK 6.1.0 in flash. The bootloader_settings_t is the same for both examples, but the size of the enum is not. This will affect the location of the struct members, and cause the new bootloader to read out the wrong values from the bootlaoder settings page in flash.

In the old version we had set the "enum as int compiler" option:

This option is disabled in the newer SDKs, and instead of enabling it again I added the BANK_UNUSED member.

typedef enum
{
    BANK_VALID_APP   = 0x01,
    BANK_VALID_SD    = 0xA5,
    BANK_VALID_BOOT  = 0xAA,
    BANK_ERASED      = 0xFE,
    BANK_INVALID_APP = 0xFF,
    BANK_UNUSED      = 0xFFFFFFF,
} bootloader_bank_code_t;

This is a somewhat hacky way of making all the members in this enum to have the size of an 'int' to avoid affecting other enums that may be used in your project. Have only tested this with Keil.

Update - the bootloader settings problem when doing DFU of BL from SDK 6.1.0 to SDK 10.0.0

A known problem with doing bootloader update from SDK 6.1.0 to one from SDK 7.x.x or later is that bootloader settings structure is stored differently in flash because of the "enum contrainer always int" option that was used before.

The picture below shows how the "enum contrainer always int" option affects the format of how the structure is stored to flash.The first line shows the result with the option enabled during SD+BL update, and the second line shows the same without it enabled (default SDK 7+). Notice the offset on every struct member after bank_0 when comparing these two.

So the problem is that the new bootloader (sdk 10.0.0) will read the wrong values from flash in the bootloader_dfu_sd_update_continue() function, hence failing to reach bootloader_dfu_sd_update_finalize() to complete the update.

When I tried this with Keil it was sufficient to add BANK_UNUSED = 0xFFFFFFF to get the same format between SDK 10.0.0 and SDK 6.1.0. as I mentioned earlier. Please make sure that you do have the same format for your bootloaders so we know that this is not why it is failing at your end.

[Dave_couling]

I will try this with the new json and init file formats.

However your last note regarding changing the bootloader_bank_code_t enumeration doesn't make sense as these are already the same in bootloader_types.h between SDK6.1 and SDK10. SDK 6.1 does not have any BANK_UNUSED = 0xFFFFFFF value in bootloader_bank_code_t nor any reference in any source code?

[Dave_couling]

Even if I bypass the CRC checks, the Images do not seem to update properly. Seems to fail at the image swap and validation. Perhaps having to do with this settings issue that is still unclear. Thanks.

[Dave_couling]

I've also checked the settings used for SD_MBR_COMMAND_COMPARE validation and SD_MBR_COMMAND_COPY_BL.

In both cases the bl_image_start = 178456 and the length variables sd_mbr_cmd.params.compare.len and sd_mbr_cmd.params.copy_bl.bl_len correctly equal 3915 (15660/4).

I tried making the init packet and json updates you mentioned, but my nRF Master Control App rejects the files and doesn't allow the DFU process to even start. So I bypass the checks for now and use the current init and json file formats.

[Vidar Berg]

Sorry, I uploaded the wrong .zip for ios earlier, uploaded the correct one now. Please try with one of the .zip files I attached and see if you still get the same problem.