nRF5340 Netcore firmware update using external flash

[djgj]

I am using NCS 1.7.0 and latest nRF5340 DK

I am trying to update netcore firmware using the process defined here: 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/nrf/ug_nrf5340.html#fota-upgrades

I am able to update the appcore and netcore using the smp_svr sample as documented  here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#smp-svr-sample

I used west tool for building the smp_svr sample

`west build -b nrf5340dk_nrf5340_cpuapp -- -DCONFIG_BOOTLOADER_MCUBOOT=y -Dmcuboot_CONFIG_PCD=y -DOVERLAY_CONFIG=overlay-bt.conf`

I also enabled logging in hci_rpmsg and modified some dummy logging message to confirm that update has happened successfully in the netcore

This sample does not use QSPI external flash for the FOTA so i modified the sample to use external flash by adding an overlay and also CONFIG_NORDIC_QSPI_NOR=y.

This modified sample works for the updating application core but does not work for network core. I am able to upload the network core binary but once i issue image test and reset commands it takes sometime to reboot but still network core has the old firmware. 

I had to use the following configs in mcuboot child image configurations to come to this state:

```

CONFIG_PCD=y

CONFIG_PCD_APP=y

CONFIG_PCD_NET=y

# # CONFIG_UPDATEABLE_IMAGE_NUMBER=2

# # CONFIG_FLASH_SIMULATOR=y

# # CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y

# # CONFIG_FLASH_SIMULATOR_STATS=n

# # CONFIG_BOOT_UPGRADE_ONLY=y

CONFIG_BOOT_SWAP_USING_SCRATCH=y

CONFIG_NORDIC_QSPI_NOR=y

CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

```

if i use the commented options above then during FOTA process device reboots continuously with a fatal error seen on network core.

I was facing a similar issue on my nRF5340 based product development (where i wanted to use CONFIG_BOOT_SWAP_USING_SCRATCH) and hence i thought it will work in devkit but i see the same issue here too on smp_svr sample application.

Kindly help me with this as I don't know what else is missing from my configurations that will enable me to update the network core using external flash QSPI.

Regards,

Dhananjay

[djgj]

Hello Edvin,
        May be i phrased it wrongly. But for me "CONFIG_BOOT_SWAP_USING_SCRATCH" did not work and when i checked in Zephyr's discord channel with Nordic Vendor thread they mentioned i need to use "CONFIG_BOOT_UPGRADE_ONLY" for updating netcore. 

Also this is mentioned as part of the Nordic document: developer.nordicsemi.com/.../ug_nrf5340.html

May be i am interpreting something wrong. But i would like some confirmation from Nordic, whether we can use "CONFIG_BOOT_SWAP_USING_SCRATCH" option for updating netcore and QSPI flash?

Thanks,

Dhananjay G J

[Edvin]

According to our SDK team, the reason we recommend CONFIG_BOOT_UPGRADE_ONLY when using an external flash chip is because if you have the opportunity to swap back to the previous FW, then the FW in the swap slot will be unencrypted on the external flash, and it is fairly easy to read it out either by tampering with the external flash chip, or by monitoring the QSPI bus.

The reason CONFIG_BOOT_UPGRADE_ONLY changes the behavior is that the new image will be encrypted, and it will not store the old (unencrypted) image on the external flash, and it is not possible to swap back (which would then expose the unencrypted new image in the QSPI flash).

Best regards,

Edvin

[Stephan Walter]

Hi Edvin, you write:

the reason we recommend CONFIG_BOOT_UPGRADE_ONLY when using an external flash chip is because if you have the opportunity to swap back to the previous FW, then the FW in the swap slot will be unencrypted on the external flash

It would seem that the mcuboot documentation contradicts this, or am I interpreting this wrong?

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/encrypted_images.html#upgrade-process

Also when swap is used, the image in the primary slot is checked for presence of the ENCRYPTED flag and the key TLV. If those are present the sectors are re-encrypted when copying from the primary slot to the secondary slot.

[Edvin]

This is a bit complex, so I don't know all the details by heart, but the scatch area is not encrypted, so if you keep the scratch area in a safe place, then the image will be encrypted when moved from the primary to secondary slot.