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

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

Dave_couling — Wed, 25 May 2016 22:36:05 GMT

HI Vidar,

I added the BANK_UNUSED = 0xFFFFFFF to my bootloader settings on the SDK10 bootloader image. However the upload is still not successful/

The settings in my previous response are the settings stored i flash. I obtain them via a Flash readback after the DFU.

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

Vidar Berg — Mon, 23 May 2016 17:22:17 GMT

Hi Dave,

Sorry, could have been more clear, but was referring to the data store in flash at 0x3FC00 by the bootloader when after it failed to update sd+bl. Updated my answer to better illustrate the problem.

SDK 6.1.0 supports softdevice and bootlaoder update, and I was able to do DFU from SDK 6.1.0/s110 v.7.x.x to SDK10.0.0/s110.v.8.0.0 after fixing the format issue.

It is very unfortunate if it has been indicated that reloaction of the bootloader would be supported. I hope it will be ok to keep the start address, but if space becomes an issue you could switch over to single bank.

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

Dave_couling — Fri, 20 May 2016 16:55:12 GMT

Hi Vidar,

My settings are the following: :10FC0000A5009D4FFF000000AC9C010018590100A9 :10FC1000944300000000000000600100FFFFFFFFB0

I tried updating the SD + boot using SD7 and old bootloader. But this exhibits the same behaviour. So I can't seem to get SD + Boot of any kind to work on a stock DFU code. Was SD + Boot supported in SDK 6.1?

Ok, we can compromise on not update the Bootloader start address but its not ideal. We were informed by Nordic early in our development this would be possible on future SDKs.

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

Vidar Berg — Fri, 20 May 2016 11:54:52 GMT

Please post the bootloader settings data @ 0x3FC00 after updating to SDK 10.0.0. This should show whether the bootloader was able to finalize the update or not.

We don't have any examples demonstrating relocation of the bootloader at runtime, and I'm not sure if it is possible to make failsafe. I think the main problem is that you will be vulnerable to resets when changing the interrupt forwarding address to the new bootloader start address (SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET). Is keeping the old start address an option? I understand it is not ideal, but not sure if there is a better alternative.

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

Dave_couling — Thu, 19 May 2016 17:40:54 GMT

What is the non-trivial way the Bootloader Address can change? We were told me Nordic a while ago during SDK6.1 that future SDK's will allow the Bootloader start address to change. Since our Bootloader is not much smaller than it was on SDK6.1 it is very inconvenient to still use the same start address.

I am not using nrf toolbox v.3.0.1 on iOS, I'm using Master Control app on Android as it has the same DFU library intergrating into my app. Yes this .zip is rejected without the JSON or .dat file. The modified version gets rejected as well. I have hardcoded to check the [3] element for CRC when updating SD + Boot. This works and the images do properly upload, validate and swap. However they do not run properly still. I've verified via readback that these images are placed properly. So there must be another compatibility issues with SDK 6.1 -> to SDK 10

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

Vidar Berg — Fri, 13 May 2016 10:47:03 GMT

Unfortunately, the bootloader address has stay the same, and is not something that can be worked around (non-trivial at least).

Is the distribituin zip still being rejected if you try nrf toolbox v.3.0.1 on iOS?

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

Dave_couling — Thu, 12 May 2016 22:08:15 GMT

Is there any way I can update the BOOTLOADERADDR?

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

Dave_couling — Thu, 12 May 2016 19:10:16 GMT

Hi Vidar,

I tried your new iOS .zip but nRF Master Control App rejects it as a valid Distributed File. I tried updating the bootloader_settings enumeration on the SDK10 bootloader that I try to DFU. I believe SD upload may be successful because after the DFU I get an assert error on SOFTDEVICE_HANDLER_INIT() which makes sense with new API for this function call.

However I think the main error is in the Bootloader upload. My current bootloader starts at 0x35000 and the new SDK10 Bootloader starts at 0x3A000. Could this cause a compatibility issue?

I tried compiling the OTA image to start at 0x35000 but DFU still fails. I verified that the SD 8 correctly uploaded via commandline readbacks. But it appears the bootloader is not uploading or swapping correctly.

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

Vidar Berg — Thu, 12 May 2016 09:04:24 GMT

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.

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

Dave_couling — Thu, 12 May 2016 03:49:59 GMT

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.

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

Dave_couling — Wed, 11 May 2016 22:42:06 GMT

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.

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

Dave_couling — Wed, 11 May 2016 21:17:08 GMT

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?

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

Vidar Berg — Wed, 11 May 2016 12:52:41 GMT

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.