Running nRF53 network core from application core flash?

[Stephan Walter]

The separation of flash memory into a region for the application core and one for the network core on the nRF5340 seems rather cumbersome and error-prone.

I'm especially thinking about robust firmware updates for both cores at the same time, including the possibility to revert an upgrade.

There are two approaches implemented in NCS/Zephyr but both have drawbacks:

1. mcuboot tries to detect if the image in the secondary slot is intended for the network core. However that code does not account for the secondary slot being on external flash, or being encrypted. Also this requires more than one cycle of writing to secondary slot and reboot.
2. Simultaneous multi-image DFU describes a method of updating multiple images, but that requires setting CONFIG_BOOT_UPGRADE_ONLY, thus a revert is not possible.

Since the application core flash is accessible from the network core, I'm thinking about having the network core firmware image located within the application core image at a fixed address.

The network core flash at 0x01000000 would then only contain a jump instruction to that fixed address in the application core flash region.

Simply by updating the application core image, the network core firmware contained within would thus be up to date as well.

The drawback is having to fit everything in the 1Mbyte of the application core flash.

Would this work or is this a completely bone-headed idea? I'm intending to try it, but would like to hear other ideas from the community or from Nordic.

[Stephan Walter]

Should have read the specification more closely (section 3.2):

The network core processor cannot execute code directly from the application core flash

My idea therefore cannot work.

Still I'm wondering how other people deal with the issue of robustly updating two cores?

Edit: seems like it would be possible to run the network core firmware from application core RAM (0x20000000).

[Øyvind]

Hello, 

I will have a look at your case. 

Stephan Walter said:

Should have read the specification more closely (section 3.2):

The network core processor cannot execute code directly from the application core flash

My idea therefore cannot work

Yes, this will not work.

Stephan Walter said:

Edit: seems like it would be possible to run the network core firmware from application core RAM (0x20000000).

Have you seen the nRF5340: Network core bootloader ? 

[Stephan Walter]

Hi Øyvind,

Thanks for your reply. I am aware of how the network core bootloader is supposed to be used.

However that has the disadvantages I described in the original post.

Running the network core from the application core RAM does work. I tried this by linking the network core firmware to run at 0x20000000 and including it in the application core firmware using incbin. For the network core flash I made a small assembly program containing the reset vector and code to change VTOR and jump to the actual image in RAM.

We would have to give up about 100kbyte of RAM and flash, but it might be the more robust choice.

[Øyvind]

Hello, 

Our developers suggest:

It's possible to implement a copy-swap method for the mcuboot+b0n(network core bootloader). Where the b0n copies the FW to RAM then mcuboot does a swap operation with the firmware stored in secondary slot/external flash etc. This way you will have reversibility. However with terms of robustness you should have 2 copies of the firmware you are going to update with since you will be replacing the firmware stored in FLASH with firmware stored in RAM so you are at risk of loosing data during a power-failure. You will also have to keep some tracking state in FLASH for the progress so that your swap will continue at the correct place if/when a power-failure occurs.

[Stephan Walter]

Thanks, we'll keep this approach in mind.

It seems rather complicated though, so if we can spare the RAM and flash space, we would probably run the network core from application core RAM, as I described.