nRF5340 DFU both cores with external flash

[caeg]

My current project is using nRF5340, NCS 2.3.0, nRF5340-DK hardware, and development environment is VS code in Windows. At present I'm struggling to get DFU working to update both the app and net cores.

I think that what's happening now is this: the dfu_application.zip is uploaded to the DK board from mobile phone over BLE, is written somewhere (how can I verify that it went to exernal flash?), and the app core firmware is updated. Then the board gets stuck in a reboot loop in mcuboot. I believe it is attempting to update the firmware for the net core and failing, then retrying endlessly.

I discovered that I can break the reboot loop by running nrfjprog --qspieraseall. A manual reset after this step brings the board back up into a functional state. Based on a time stamp in a printk the app core updated but the net core is running its original firmware.

Help getting the DFU working to update firmware for both cores will be much appreciated!

0753.hci_rpmsg.conf0257.mcuboot.confmcuboot.overlaydts.overlay4061.prj.conf

[caeg]

Hi Sigurd,

The project got busy and we needed to make progress on other features so OTA has been laid aside for the past few months. We're back to it now. I saw the invitation for the upcoming OTA webinar and decided I should get this dusted off so I'll be ready. :-)

I've cloned your repo again and built the sample in the mcuboot_smp_ble_simultaneous directory. This is for nrf5340dk_nrf5340_cpuapp board in Windows 10 with SDK 2.5.0, on the command line in a bash shell opened via Toolchain Manager. This configuration worked - repeatedly! I've pushed an OTA update from nRF Connect on Android to the device multiple times and confirmed both nRF5340 cores are updated. This is all as per the README.md file in that repo.

We're using the _ns configuration in our project though so I tried building the sample for nrf5340dk_nrf5340_cpuapp_ns. This doesn't work: mcuboot complained "Unable to find bootable image".

My thoughts went first to partition manager. I've copied the generated partition.yml file from both builds (ns and not), copied the non-ns one to pm_static.yml, and started merging pieces from the ns version into my pm_static.yml. The result was inconclusive - I couldn't boil it down to a particular piece that reliably correlated to an image that booted or not.

Do you have any suggestions about the bootable image problem, or (better) about the bigger issue of running OTA in combination with an _ns target?

[Sigurd Hellesvik]

Welcome back!

Can you try the same for v2.5.2?
I tried to build my sample for this version, and it builds and runs (first time at least did not try further) for _ns target.
Or do you mean that it can not find the new image after DFU?

If not we will have to figure out what differs from our installs here.
Note: I did not test that sample very thurroughly for the _ns target before, so I would not be surprised if there are any errors here.

Regards,
Sigurd Hellesvik

[caeg]

OK, I've done the same with SDK v2.5.2: rm -rf build; west build -b nrf5340dk_nrf5340_cpuapp; west flash --recover. This boots on my 5340DK board. Repeating the steps, except building for _ns target, I get the same mcuboot error. And yes you understood correctly, this occurs when I flash the image directly over USB/Jlink. This 2.5.2 was installed only last week so I haven't had much opportunity to make (and forget) changes in it yet. ;-)

I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
E: Image in the primary slot is not valid!
E: Unable to find bootable image

[Sigurd Hellesvik]

I tried again now, and got that issue.

So it was just I who had missed something

But that is good, now I can get into debugging this on my side.

[Sigurd Hellesvik]

I think this is fixed in https://github.com/vidarbe/sdk-nrf/commit/00ee7b3e0a562304dca7c8da2d3ad4c5b6cc3e9d which should be part of v2.6.0.