search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.48k stars 6.41k forks source link

Rpmsg initialisation on nRF53 may fail #33768

Closed sw closed 3 years ago

sw commented 3 years ago

boards/arm/nrf5340dk_nrf5340/nrf5340_cpunet_reset.c has an initialization priority of 50 by default: https://github.com/zephyrproject-rtos/zephyr/blob/7ce8c776504f80296d0c107581f908d674dc762a/boards/arm/nrf5340dk_nrf5340/nrf5340_cpunet_reset.c#L83 This module resets the nRF53 network core by releasing the FORCEOFF flag.

If you use rpmsg to communicate between application core and network core, the rpmsg service is initialized earlier (priority 48): https://github.com/zephyrproject-rtos/zephyr/blob/7ce8c776504f80296d0c107581f908d674dc762a/subsys/ipc/rpmsg_service/rpmsg_service.c#L164

We have seen problems with the BLE functionality after a reboot. This would occur after issuing shell command kernel reboot cold, but not after a power cycle. The problem would also only occur when the debugger is not connected.

I suspect the init priority is the problem here.

I suggest the priority in nrf5340_cpunet_reset.c to be changed to less than CONFIG_RPMSG_SERVICE_INIT_PRIORITY

ioannisg commented 3 years ago

will take a look

ioannisg commented 3 years ago

@sw have you tried to use a lower priority for the cpu-net reset function? If so, did that solve your problem?

ioannisg commented 3 years ago

Copying @hubertmis (had an offline chat about this)

It seems that rpmsg boot sequence requires the host initialization and endpoint registration precede the remote initialization, hence the rpmsg service has lower priority than the service that enables and resets the Network core from the Application side.

If the problem only appears after the kernel reboot cold (and not in a regular cold reboot via a power cycle), maybe this could be the path to investigate? CC @jakub-uC as the shell maintainer

ioannisg commented 3 years ago

@sw any updates here?

sw commented 3 years ago

We are now using CONFIG_RPMSG_SERVICE_EP_REG_PRIORITY for remoteproc_mgr_boot, which is not exactly elegant but works for us. I realize now that this contradicts what you said about initialization ordering.

ioannisg commented 3 years ago

Thanks for comping back @sw I wonder if the issue could be closed?

ioannisg commented 3 years ago

Closing this. @sw if this pops up again, in a similar scope, you are welcome to re-open, or open a new ticket.