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,

[Dave_couling]

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.

[Dave_couling]

Is there any way I can update the BOOTLOADERADDR?

[Vidar Berg]

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?

[Dave_couling]

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

[Vidar Berg]

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.