Issues with XIP execution from external QSPI on nRF with MCUBOOT

[Remi Moessner]

Hi all,

I am trying to execute an application in XIP mode from an external QSPI flash on an nRF device (nRF5340, Zephyr + MCUBOOT). The setup is:

• Partition file:pm_static.yml

#### Internal flash layout ####

mcuboot:
  address: 0x0
  end_address: 0x10000
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  region: flash_primary
  size: 0x200
# unused_1:
#   address: 0x10200
#   end_address: 0xf0000
#   region: flash_primary
#   size: 0xdfe00
settings_storage:
  address: 0xf0000
  end_address: 0x100000
  region: flash_primary
  size: 0x10000


#### QSPI flash layout ####
app:
  address: 0x10000200
  end_address: 0x10200000
  region: external_flash
  size: 0x1FFE00

mcuboot_primary:
  address: 0x10000000
  device: external_flash
  end_address: 0x10200000
  region: external_flash
  size: 0x200000
mcuboot_primary_pad:
  address: 0x10000000
  end_address: 0x10000200
  region: external_flash
  size: 0x200
mcuboot_primary_app:
  address: 0x10000200
  device: MX25R64
  end_address: 0x10200000
  region: external_flash
  size: 0x1FFE00

mcuboot_secondary:
  address: 0x10200000
  device: MX25R64
  end_address: 0x10400000
  region: external_flash
  size: 0x200000
mcuboot_secondary_pad:
  address: 0x10200000
  end_address: 0x10200200
  region: external_flash
  size: 0x200
mcuboot_secondary_app:
  address: 0x10200200
  device: MX25R64
  end_address: 0x10400000
  region: external_flash
  size: 0x1FFE00


unused_qspi_1:
  address: 0x10400000
  device: MX25R64
  end_address: 0x10800000
  region: external_flash
  size: 0x400000

#### OTP flash layout ####
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc

#### SRAM layout ####
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
sram_primary:
  address: 0x20000000
  end_address: 0x20070000
  region: sram_primary
  size: 0x70000

• prj.conf snippet: 

CONFIG_PM_EXTERNAL_FLASH_BASE=0x10000000

• The QSPI is correctly flashed using west flash.

I am facing multiple issues and would appreciate guidance on the correct procedures.

Problem 1: MCUBOOT fails to boot

• Symptom: MCUBOOT crashes at startup because it cannot find the image.

• Investigation:

  • boot_rom_address_check() identifies the image that should execute at 0x10000200.

  • However, f_off is 0x0 and IMAGE_F_ROM_FIXED is set

• Questions:

  1. What is the proper procedure to fix this?

  2. Is my pm_static.yml incorrect?

  3. Is f_off misconfigured?

  4. Should I remove IMAGE_F_ROM_FIXED?

Problem 2: Application hardfault when starting manually

• Symptom: When starting the application manually (setting SP and PC after QSPI initialization in MCUBOOT), it crashes during QSPI initialization.

• Cause: qspi_workaround_215_43_apply() temporarily disconnects the QSPI by modifying pinmux. As we are executing from flahs

• Attempted solution: Relocate QSPI driver code to RAM:

  zephyr_code_relocate(FILES
  ${ZEPHYR_BASE}/../modules/hal/nordic/nrfx/drivers/src/nrfx_qspi.c
  LOCATION RAM_TEXT
  )

  
  
  

• Outcome: The code is relocated, but jumping to it causes a hardfault (likely MPU related).

• Question: What is the recommended way to safely relocate functions to RAM for QSPI initialization? Should certain MPU configurations or function attributes be used?

Problem 3: XIP offset strategy

• Goal: Adjust xip_offset to avoid swapping two images in QSPI.

• Question: Is there a recommended approach or best practice for using xip_offset in this scenario?

Thanks for your help

Rémi

[Vidar Berg]

Hello Rémi,

The mcuboot direct xip feature is currently not supported with external memory.  However, since executing code from directly from QSPI flash also adds a significant performance penalty in terms of execution speed and power consumption compared to running code from internal flash (see Indication of XIP performance) I would recommend consiering the QSPI XIP split image approach described here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/qspi_xip_split_image.html instead. This is assuming that goal is to free up internal memory.

Best regards,

Vidar

[Remi Moessner]

Hello VIdar,

Thanks for your answer

Vidar Berg said:

The mcuboot direct xip feature is currently not supported with external memory. 

OK, is it planned ?

Vidar Berg said:

However, since executing code from directly from QSPI flash also adds a significant performance penalty in terms of execution speed and power consumption compared to running code from internal flash (see Indication of XIP performance) I would recommend consiering the QSPI XIP split image approach described here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/qspi_xip_split_image.html instead. This is assuming that goal is to free up internal memory.

I based my initial investigation on this example and tried to simplified to avoid using internal memory :)

The main advantage of using external QSPI is to avoid SWAP during update (by using xip_offset). Do you have any solution to avoid swapping between two bank with a split image ? Is it possible ?

Thanks

Best Regards,

Rémi

[Vidar Berg]

Hello Rémi,

I'm not aware of any plans to add support direct-xip with external memory on this device, and I'm not sure how much effort it will take. Based on your current findings it seems that you will at least need to run parts of the application such as the QSPI driver from flash.

Remi Moessner said:

The main advantage of using external QSPI is to avoid SWAP during update (by using xip_offset). Do you have any solution to avoid swapping between two bank with a split image ? Is it possible ?

But is reducing the FW activation times with a few seconds worth performance reduction during normal operation? Your FW is going to run differently depending on whether it's being executed from internal or external flash which also may increase your test requirements.

Best regars,

Vidar