Simultaneous dfu on nRF5340 ncs2.6 without external flash with TFM

[leadrover]

I've managed to build and flash the project mentioned in this link(devzone.nordicsemi.com/.../459668) to the nrf5340dk with TFM disabled. However, when I attempt to build the project with TFM enabled the project builds, and flashes, but MCUBoot is unable to find a bootable image.

I think I'm missing something obvious but I can't seem to wrap my head around it at the moment. Can someone please point me to the required documentation, or help me understand what I'm missing. I'm assuming I need to update the static partitions etc to build this application with TFM enabled?

To successfully build the project listed in the linked dev zone solution I had to remove the MCUBOOT version config from prj.conf, as well as remove the encryption disable settings in the nrf5340dk_nrf5340_cpuapp.conf file under child_image/mcuboot/boards/. To build the application with non secure firmware, I created duplicates of the config and overlay files with the added _ns label.

[AHaug]

Hi,

Could you state what version of NCS you're working with? Is it the same as in the case you're referring to, i.e NCS v2.4.0? I'm guessing there might be a conflict in between the provided sample/solution and the version you're working on

Here's a link to the simultaneous multi image DFU for the 53-series: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html#simultaneous_multi-image_dfu as well as a link to the TFM documentation https://docs.nordicsemi.com/bundle/ncs-latest/page/tfm/index.html 

Could you also post any build error logs you get when trying to build with TFM and I'll get back to you next week?

Kind regards,
Andreas

[leadrover]

G'day AHaug,

I'm using NCS version 2.6. There are no build errors once I make the adjustments I mentioned. However, I can build the _ns version for the dev kit, but MCUBoot is unable to find any valid images. Here is the output from serial:

I: Starting bootloader
I: Image index: 0, Swap type: nonepen /dev/tty.usbmodem0010500279
I: Image index: 1, Swap type: none
E: Unable to find bootable image

I'm also curious as to whether we can use NAND flash with the overlay or if we require NOR flash for DFU. Even if we're not using the flash for the bootloader. At this stage we need to create a phantom NOR flash entry in the device tree to get the simultaneous multi image DFU working on our hardware.

Cheers,

[AHaug]

Hi,

Thank you for sharing. I will try to set this up myself this week and see if it is possible. I need to verify some potential suspects that may cause issues or not

1. While waiting, you could you also try to log fih_rc and see where and when the error occurs in mcuboot/boot/zephyr/main.c https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/main.c 
   
   
   
2. Could you also share your partition map for both the original firmware and for the update build?
3. Could you also share your pfj.conf?
4. Could you verify if you make changes to the firmware (at minimum add a print/log/change fw version number) before you build the image you use for image?
5. As a sanity check could you also verify what file you use for the update (if it app_update.bin or other)?

leadrover said:

I'm also curious as to whether we can use NAND flash with the overlay or if we require NOR flash for DFU. Even if we're not using the flash for the bootloader. At this stage we need to create a phantom NOR flash entry in the device tree to get the simultaneous multi image DFU working on our hardware.

Unfortunately we don't have any support for NAND flashes in our SDK, so any implementation to get support will have to be proprietary solutions created by the individual developers using our products

Kind regards,
Andreas

[leadrover]

G'day Andreas,

Thanks for the update on the NAND flash. I'll look into working on that at a later stage. Sorry for the delay in reply.

To answer your questions:
1. fih_rc is giving (int) 357913941.

2. The pm_static.yml file:

app:
  address: 0x10200
  end_address: 0x66000
  region: flash_primary
  size: 0x55E00
mcuboot:
  address: 0x0
  end_address: 0x10000
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x66000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x56000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x66000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x55E00
  span: *id002
mcuboot_secondary:
  address: 0x66000
  end_address: 0xBC000
  size: 0x56000
mcuboot_secondary_1:
  address: 0xBC000
  end_address: 0xFC000
  size: 0x40000
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  region: sram_primary
  size: 0x2000
ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
settings_storage:
  address: 0xFC000
  end_address: 0x100000
  region: flash_primary
  size: 0x4000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000
mcuboot_primary_1:
  address: 0x0
  size: 0x40000
  device: flash_ctrl
  region: ram_flash

3. prj.conf file:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Lotic_LBS"

# Enable the LBS service
CONFIG_BT_LBS=y
CONFIG_BT_LBS_POLL_BUTTON=y
CONFIG_DK_LIBRARY=y

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y


CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

and nrf5340dk_nrf5340_cpuapp_ns.conf within MCUBOOT child image directory tree:

# Enable support for Simultaneous multi-image DFU
# The following configurations are required to support simultaneous multi image update
CONFIG_PCD_APP=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_BOOT_UPGRADE_ONLY=y
CONFIG_BOOT_IMAGE_ACCESS_HOOK_NRF5340=y
CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
# The network core cannot access external flash directly. The flash simulator must be used to
# provide a memory region that is used to forward the new firmware to the network core.
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n


# Use most of the configuration from the sdk-mcuboot/boot/zephyr/prj_minimal.conf

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_FLASH=y
CONFIG_FPROTECT=y
CONFIG_PM=n

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n

CONFIG_BOOT_BOOTSTRAP=n

CONFIG_ASSERT=n
CONFIG_BOOT_BANNER=n
CONFIG_CONSOLE=y
CONFIG_CONSOLE_HANDLER=n
CONFIG_GPIO=n
CONFIG_I2C=n
CONFIG_SPI=n
CONFIG_NORDIC_QSPI_NOR=n
CONFIG_KERNEL_MEM_POOL=n
CONFIG_LOG=y
CONFIG_MINIMAL_LIBC_CALLOC=n
CONFIG_MINIMAL_LIBC_MALLOC=n
CONFIG_MINIMAL_LIBC_REALLOCARRAY=n
CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_NO_RUNTIME_CHECKS=y
CONFIG_NRF_RTC_TIMER=y
CONFIG_PRINTK=y
CONFIG_REBOOT=y
CONFIG_RESET_ON_FATAL_ERROR=y
CONFIG_SECURE_BOOT_DEBUG=n
CONFIG_SERIAL=y
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_UART_CONSOLE=y
CONFIG_HW_CC3XX=n
CONFIG_NRF_CC3XX_PLATFORM=n
CONFIG_BUILD_WITH_TFM=y

4. I haven't made any changes to the firmware prior to raising the ticket, but I did add the debug for mcuboot to get the error code above for this reply.

5. I tried to flash the image to the development kit using 'west flash --recover' just like I did when using the non _ns version to compile.

Cheers.

[AHaug]

Hi,

Thank you for sharing this as well and no worries about the response time

leadrover said:

Thanks for the update on the NAND flash. I'll look into working on that at a later stage. Sorry for the delay in reply.

Noted, do also note that we don't give any guarantee that any proprietary solutions using NAND flash will work as we don't test for this type of flash devices, but I've heard of non-Nordic developers having their own solutions for NAND flashes.

AHaug said:

Thank you for sharing. I will try to set this up myself this week and see if it is possible. I need to verify some potential suspects that may cause issues or not

Another item for discussion that I should've brought up in my initial reply is the aspect of not using an external flash to do DFU for the nRF5340. You might've already thought of this aspect, but nonetheless could you expand upon the motivation for why you're not using an external flash?

You might already know this, but I'll explain anyways: how DFU with MCUboot works (non-serial recovery procedures atleast), and partitioning in NCS/Zephyr works, is that the partition manager will split the internal flash into two equally large sections + the sections for bootloader(s) and custom storage.

This means that the two equally large sections will be limiting your maximum application size, and if you do simultaneous DFU, the largest application size will be approximately be 

application flash size ~= Internal appcore flash size - mcuboot - secondary slot for app core - secondary slot for net core

-> app size ~= 1MB - mcuboot size - app size - 256

-> app size ~= (1MB - ~48kB - 256kB)/2 ~= 360kB 

~360kB room for an application using both BLE and TF-M is not much room, although you will save some since the netcore will do most of the BLE activity (do note that I've used the standard MCUboot size, you can do a minimal MCUboot configuration which would give you ~10kB more for the application(

Explained with graphics in this repository, which is the foundation for the DFU topic in our latest academy course : https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340 and illustrated as:

I should've explained this on friday, but it didn't cross my mind then.

Anyways, to summarize: 

It is possible to do simultaneous DFU not using an external flash, but you must consider the flash limitations for your application. I am currently trying to create a sample showcasing this + TF-M and hopefully I have one ready for you today.

Kind regards,
Andreas