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

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

Amanda Hsieh — Wed, 18 Sep 2024 18:30:49 GMT

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.

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

zhaw-moss — Wed, 18 Sep 2024 06:22:21 GMT

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

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

Amanda Hsieh — Tue, 17 Sep 2024 15:21:22 GMT

Hi,

[quote user="zhaw-moss"]

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?

[/quote]

Your understanding is correct.

[quote user="zhaw-moss"]

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?

[/quote]

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

-Amanda H.

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

zhaw-moss — Tue, 17 Sep 2024 06:11:12 GMT

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.

Am I on the right track with this thinking?

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

Best regards,
Simon

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

Amanda Hsieh — Mon, 16 Sep 2024 20:53:24 GMT

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.