IPC interrupt priority appears to be fixed at level 0 when using message services

[Kevin Doss]

When IPC message services are being used for message passing between application and network CPUs (for example):

CONFIG_IPC_SERVICE=y

CONFIG_IPC_SERVICE_BACKEND_RPMSG=y

CONFIG_IPC_SERVICE_RPMSG=y
CONFIG_IPC_SERVICE_STATIC_VRINGS=y

It appears that the IPC interrupt handler priority gets statically configured to level 0 in NCS source module /zephyr/drivers/ipm/ipm_nrfx_ipc.c, function gipm_init().

The system that I'm developing is using the radio and timer peripherals (among others) on the network CPU to implement a proprietary wireless protocol and the interrupt handlers for the RADIO and TIMER IRQs cannot tolerate being delayed or preempted by message handling.

Is there really no way to configure the IRQ priority of the IPC message service short of patching this NCS source module?

[Amanda Hsieh]

Hi, 

Looking at the code in `gipm_init()` :

IRQ_CONNECT(DT_INST_IRQN(0),
            DT_INST_IRQ(0, priority),
            nrfx_isr, nrfx_ipc_irq_handler, 0);

It seems the priority is selected from a device tree entry. Inside zephyr/dts/arm/nordic/nrf5340_cpunet.dtsi I can find the following node:

mbox: ipc: mbox@41012000 {
                        compatible = "nordic,mbox-nrf-ipc", "nordic,nrf-ipc";
                        reg = <0x41012000 0x1000>;
                        tx-mask = <0x0000ffff>;
                        rx-mask = <0x0000ffff>;
                        interrupts = <18 NRF_DEFAULT_IRQ_PRIORITY>;
                        #mbox-cells = <1>;
                        status = "okay";
                };

And it looks the IRQ priority can be modified by overriding the `interrupts` property of this node. 

Regards,
Amanda H.

[Kevin Doss]

Amanda,

One follow-up question... what's still not clear to me is that just prior to the IRQ_CONNECT() macro is this:

#if IS_ENABLED(CONFIG_IPM_NRF_SINGLE_INSTANCE)
nrfx_ipc_init(0, nrfx_ipc_handler, (void *)&nrfx_ipm_data);
#else
nrfx_ipc_init(0, vipm_dispatcher, (void *)&nrfx_ipm_data);
#endif

And inside nrfx_pic_init() in source module nrfx_ipc.c is this:

    NRFX_IRQ_PRIORITY_SET(IPC_IRQn, irq_priority);

    NRFX_IRQ_ENABLE(IPC_IRQn);

 

Does the IRQ_CONNECT() macro then override the call to nrfx_ipc_init() that specifies priority=0?

Thank you,

Kevin D.

[Amanda Hsieh]

Hi, 

We see the nrfx sets IRQ priority and enables it in
https://github.com/zephyrproject-rtos/hal_nordic/blob/6c9f23498ee6a225fee049c8c5b2e1ac760bd4a8/nrfx/drivers/src/nrfx_ipc.c#L57-L58

However, just after calling nrfx_ipc_init, IRQ_CONNECT is executed, setting, as expected in Zephyr, the priority defined in DT.

The team thinks:

• HAL should *NOT* be dealing with IRQs, this is Zephyr's domain. It should be fixed.
• Interrupt priority can be overridden in the application. Overriding IRQ prior in DT is a bit cumbersome, that's why we have "NRF_DEFAULT_IRQ_PRIORITY", however, it will change the priorities of all peripherals. Here's an example on how to override it: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/hci_rpmsg/dts/arm/nordic/override.dtsi. In case you only need to change the priority for IPC, you can do &ipc { interrupts = <18 XXX>; }; in your app.

Regards,
Amanda H.

[Kevin Doss]

Thanks so much for your response. This was a misunderstanding on my part. We do in fact have an mbox node in our devicetree that sets the priority to a lower value.