nRF5340: Understanding Application Core to Network Core Interface Changes in DFU

[zhaw-moss]

Hi,

I'm a bit confused regarding the DFU process for the nRF5340:
Under what conditions would the interface between the application core and the network core change?

I need to implement FOTA over BLE, but I don't have access to any external flash storage.

According to the documentation here (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/features_nrf53.html#dual-core_architecture), "The separation of application and network functionalities simplifies firmware updates, allowing modifications on one processor without affecting the other." Additionally, the cores can be updated separately, as noted here (https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340#non-simultaneous-update).

This works as expected with the available samples. However, if the interface between the app core and the net core changes, a simultaneous update would be required (https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340#simultaneous-update). However, I want to make sure this is not necessary, as I wouldn't be able to perform one without an external flash.

My question is: how can I determine if and when the interface between the app core and net core changes? I tend to think of the image on the net core as being similar to a Soft Device, which wouldn’t change unless a significant update to the BLE stack is made. I understand things work differently with Zephyr, but I'm struggling to grasp the specifics.

Thank you very much for your assistance.

Best regards,
Simon

[Amanda Hsieh]

Hi, 

The interface between the network core and the application core in nRF5340 is managed through Interprocessor Communication (IPC). IPC allows for inter-core communication between the two cores. Communication between the application core and the network core happens through a shared memory area. The application core memory is mapped to the network core memory map, which means that the network core can access and use the application core memory for shared memory communication.

If you update the interface between the net and app cores, you must update them at the same time. If not, you will not be able to update the second core after the first one has been updated.

Regards,
Amanda H.

[zhaw-moss]

Hi Amanda,

Thank you for your reply. I appreciate the clarification on how the IPC between the network core and the application core works. However, my question is more about understanding the specific scenarios where the interface between the cores would change.

From my understanding, typically, the Controller and Host are split, meaning the IPC would primarily consist of HCI commands, which are handled over OpenAMP using the RPMsg protocol. In this case, as long as the HCI API remains unchanged and OpenAMP remains stable, the interface between the cores should not need modification. The HCI protocol tends to be backward-compatible, with features generally being added rather than modified. So, in theory, the only potential point of concern would be changes in the RPMsg implementation, which should remain stable if the nRF Connect SDK version is consistent.

Am I on the right track with this thinking?

For instance, consider an application that only does BLE advertising, such as transmitting temperature data from a sensor. If I later update the application to also support ANT+ advertising, I would enable multiprotocol services and first update the application core. In that scenario, I would expect the app to handle HCI errors gracefully while attempting to use the new multiprotocol features, meaning I could still proceed with a subsequent network core update to add the actual multiprotocol support. Alternatively, I could compile a more comprehensive Controller stack to potentially avoid network core updates altogether.

I suspect I might be overlooking something here. What are your thoughts on this approach?

Best regards,
Simon

[Amanda Hsieh]

Hi,

zhaw-moss said:

From my understanding, typically, the Controller and Host are split, meaning the IPC would primarily consist of HCI commands, which are handled over OpenAMP using the RPMsg protocol. In this case, as long as the HCI API remains unchanged and OpenAMP remains stable, the interface between the cores should not need modification. The HCI protocol tends to be backward-compatible, with features generally being added rather than modified. So, in theory, the only potential point of concern would be changes in the RPMsg implementation, which should remain stable if the nRF Connect SDK version is consistent.

Am I on the right track with this thinking?

Your understanding is correct. 

zhaw-moss said:

For instance, consider an application that only does BLE advertising, such as transmitting temperature data from a sensor. If I later update the application to also support ANT+ advertising, I would enable multiprotocol services and first update the application core. In that scenario, I would expect the app to handle HCI errors gracefully while attempting to use the new multiprotocol features, meaning I could still proceed with a subsequent network core update to add the actual multiprotocol support. Alternatively, I could compile a more comprehensive Controller stack to potentially avoid network core updates altogether.

I suspect I might be overlooking something here. What are your thoughts on this approach?

Your approach seems reasonable if the requirement for the IPC is still the same at that time. 

-Amanda H.

[zhaw-moss]

Hi Amanda,

Thank you for your confirmation. I appreciate your insights so far.

To clarify, my previous example was just a simplified toy case to make a point. What I’m genuinely concerned about is the risk involved in rolling out a device to production that cannot perform a simultaneous upgrade.

Specifically, my fear is that if we ship devices and they are deployed in the field, we’d only be able to update them successfully until someone changes the IPC implementation. For example, certain features that are currently missing from Nordic's SoftDevice (like Angle of Departure) will likely be added in future SDK releases. If these updates introduce changes in the IPC—whether it's due to modifications in the HCI commands, the RPMsg protocol, or OpenAMP itself—there's a risk that we wouldn’t be able to perform a non-simultaneous upgrade.

I’m trying to understand what the real-world risk is for us if we launch a product that doesn't support simultaneous upgrades. Should we be concerned about future SDK updates requiring simultaneous core updates due to IPC changes? Are there any specific scenarios or changes that could potentially block us from updating the device in such a situation?

Thanks again for your help. Your guidance on this would be invaluable.

Best regards,
Simon

[Amanda Hsieh]

Hi, 

Your concerns are valid. When it comes to updating the cores of a device, there are indeed risks involved if the device does not support simultaneous updates. If future SDK updates introduce changes in the IPC, there is indeed a risk that non-simultaneous upgrades would not be possible. This could potentially block you from updating the device in such a situation.

It's important to consider these factors when planning your product launch and to ensure that your devices support simultaneous updates to mitigate these risks.

-Amanda H.