We are working on a project where 802154 radio runs on the NetCore. The NetCore firmware is based on the multiprotocol_rpmsg example by Nordic. Additionally, we have a custom function implemented in the NetCore that is called from the AppCore using RPC.
The issue arises during initialization. The AppCore attempts to execute nrf5_init from ieee802154_nrf5.c, but the nrf5_get_capabilities_at_boot function never returns, causing a cold reboot. This occurs because the capabilities_await function in nrf_80524_spinel_app.c times out.
Upon further investigation, in the NetCore, we noticed that the nrf_rpc_init function is called during the POST_KERNEL phase, as suggested in the entropy_nrf53 example. However, the function never completes, seemingly getting stuck in an infinite loop within the transport_init function in nrf_rpc.c.
This issue causes the AppCore to reset continuously. In most cases, the problem resolves itself after a few resets, and the system operates as expected. As a result, we didn't catch this issue initially. However, in some cases, the system remains in a continuous reset loop. This behavior is consistently reproducible when the AppCore is connected to the Ozone debugger and a soft reset is triggered.
We found that calling nrf_rpc_init after the HCI endpoints are initialized in the NetCore (as seen in the multicore_rpmsg example, inside main()) or when both 802154 radio and RPC share the same IPC channel resolves the issue.
My question is: Is there a specific initialization order that must be followed when multiple IPC channels are involved? If so, what causes the issue to resolve itself after a few reboots? Any insights into this behavior would be greatly appreciated.
Thank you for your assistance!
HW : NRF5340
FW : sdk-nrf - 2.4.2
