1.6.99 - nRF5340 - RPC_Host Sample execution, stuck in fault_s.S

[MGSC]

Hi, 

After many attempts I was unable to make RPC_Host sample work (link to the related nRF Connect SDK doc).

From SES in debugging mode, the network core gets stuck in an early initialization stage without ever reaching the __main call.
Idem when flashing (merged_domain.hex) the sample from nRF_ Connect_Programmer (Nothing on the network_core console / Beacon sample stuck waiting for the network core to register).

So far, other samples worked as expected.

Can someone try to guide me into where I could have missed a step with rpc_host sample ?

Please find below infos relative to my setup :

devKit : PCA10095 / 1.0.0 / 2021.10
Sdk : 1.6.99 (fresh install)
IDE : SES5.6

Network core (target : nrf5340-dk-nrf5340-cpunet) : 

- unmodified rpc_host sample.
--> exec state : stuck in fault_S.s
----> my guess : triggered by virtio (?)

There is one "error" shown in SES while programming the network core: 

Illegal value 0x210089D8 written to register 66 (MSP_NS) ignored

Application core (target : nrf5340-dk-nrf5340-cpuapp) :

- Tried with unmodified sample (via menuconfig from rpc_host in SES) nrf:empty_app_core
- Tried with unmodified sample (via CONFIG_BT_RPC option) zephir:beacon
--> exec. state : waiting for network core to register. In nrf_rpc_rpmsg.c l.136 (while (!rpmsg_service_endpoint_is_bound(endpoint_id)){...}  )

Best regards,

Maxime

[MGSC]

Hi,

Digging a little bit more in debugging mode (network core rpc_host, app core running empty_app_core via menuconfig).

The fault seems to occur while executing "z_sys_init_run_level(_SYS_INIT_LEVEL_PRE_KERNEL_1);" line l.436 from init.c.
The execution goes 2 times without success in for loop l.82 of device.c then at the 3rd attemp the CPU lock itself into fault_S.s.

The flag SHCSR->BUSFAULTACT get to 1 which mean "BusFault exception active bit" (BUSFAULTENA been enabled).

nRF DCNF doc extract : An attempt to access the blocked resources will trigger a BusFault or a HardFault exception, depending on the value of the BUSFAULTENA bit in the ARM Cortex-M33 SHCSR (system handler control and state register), described in the ARM Cortex-M33 Devices Generic User Guide.

Link to The domain configuration (DCNF)

Any idea of why and how to fix ? 

Maxime

[Marte Myrvold]

Hi Maxime,

Thank you for providing additional information. I have started looking into your issue, but I do not have a solution yet. I will come back to you with more information soon.

Best regards,

Marte

[Marte Myrvold]

Hi Maxime,

Thank you for your patience.

I was able to reproduce your issue, but could not figure out what caused it, so I asked our developers. There were some changes in RPC transport to which the RPC host sample was not aligned. The fix for this came only a few days ago, and it is on both the master branch and on the tag for release candidate 1, v1.7.0-rc1, now: https://github.com/KAGA164/fw-nrfconnect-nrf/blob/ed5ab21fd1b3b0a5dd431c43e771a5e572eaf1b0/samples/bluetooth/rpc_host/prj.conf#L14

I tested the fix with the Beacon sample, with CONFIG_BT_RPC=y, and I could see in the terminal that the RPC host started, as it printed “Starting nRF RPC bluetooth host”. Please let me know if this does not fix the issue on your side.

Best regards,

Marte

[MGSC]

Hi Marte,

Thanks for your support and explainations.

I checked with V1.7.0-rc1 tag, it work as you've described 

Have a good day !

Maxime

[Marte Myrvold]

Hi Maxime,

I am glad to hear that it fixed the issue on your side as well!

Thanks, you too!

Best regards,

Marte