nRF9160 + external flash + MCUboot: buggy flash protection configuration in SDK

There seems to be a bug in the nRF Connect SDK when attempting to use external flash for the secondary MCUboot partition on nRF9160.

Please see the minimal project for nRF9160DK (HW revision 0.14.0 or newer) that exhibits this issue here: https://drive.google.com/file/d/1kOiagY32qmYNR3Wf0BVROqHCjH_8xePm/view?usp=sharing

When MCUboot and TrustedFirmware-M are both in use, the CONFIG_BOOTLOADER_MCUBOOT option is propagated to TF-M (https://github.com/nrfconnect/sdk-nrf/blob/v2.0.0/modules/tfm/zephyr/CMakeLists.txt#L115), which in turn enables the BL2 option (https://github.com/nrfconnect/sdk-nrf/blob/v2.0.0/modules/tfm/tfm/boards/CMakeLists.txt#L34) and that declares a flash region (https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.5.0-ncs2/platform/ext/target/nordic_nrf/common/nrf9160/target_cfg.c#L420) which TF-M will try to configure as non-secure (https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.5.0-ncs2/platform/ext/target/nordic_nrf/common/nrf9160/target_cfg.c#L552).

Apparently the flash protection only works for the internal flash, so the spu_regions_flash_config_non_secure() function hard-faults and consequently the board enters a boot loop.

A workaround is to manually override the TFM_CMAKE_OPTIONS property (see the commented out line in the attached project's CMakeLists.txt) so that CONFIG_BOOTLOADER_MCUBOOT is set to false in the TF-M child image. However I believe this should be addressed somewhere in the SDK itself, so that setting flash protection for the secondary partition is not attempted when the secondary MCUboot partition lies on external flash.

Related