CONFIG_ZERO_LATENCY_IRQS (ZLI) and MPSL - blocking IRQs not possible?

[douglas.malnati]

It appears that MPSL is using Zero Latency IRQs, and I'm not able to disable that.

I set the config param to 'n' in my prj.conf file, but as noted, it isn't taking effect.

Navigating to the Kconfig menu, I see it is not possible to uncheck this feature.

This is very problematic for me, as blocking IRQs is a very necessary component of my software, and the ZLI is punching right through my IRQ locks.  This is leading to state corruption.

How can I disable ZLI?

Or what am I supposed to do about the corruption?

I have seen the Nordic-authored article  Updating to the MPSL Timeslot interface  which seems to attempt to bypass this issue by handing events off to another blockable ISR.  However, the MPSL API requires synchronous replies, which demands looking at and interacting with application state, which is the very thing causing state corruption.

Even in the article's associated example code, there is not a solution to this problem.  It is simply not dealt with, and the application logic is dragged across multiple layers in a very confusing way to try to work around it.

MPSL should not use ZLI.

I want to either disable ZLI globally, or disable MPSL's use of ZLI, or block ZLI (nonsense of course).

How can I do any of the above?

Thanks.

[douglas.malnati]

To add more detail here, specifically I am not able to block (using irq_lock()):

MPSL_TIMESLOT_SIGNAL_START and MPSL_TIMESLOT_SIGNAL_TIMER0.

I am, for example, able to block MPSL_TIMESLOT_SIGNAL_TIMER0.

At this point I have not experimented with the other signals so I don't know if they can be blocked.

The mpsl_timeslot.h explains the START and TIMER0 signals execute in the TIMER0 IRQ handler context.

    MPSL_TIMESLOT_SIGNAL_START            = 0,  /**< This signal indicates the start of the timeslot.

                                                The signal will be executed in the same context as

                                                @ref MPSL_IRQ_TIMER0_Handler. */

    MPSL_TIMESLOT_SIGNAL_TIMER0           = 1,  /**< This signal indicates the TIMER0 interrupt.

                                                The signal will be executed in the same context as

                                                @ref MPSL_IRQ_TIMER0_Handler. */

I notice that the CONFIG_COUNTER_TIMER0_ZLI is set to n.

So I'm unclear on why an irq_lock() isn't preventing these signals from firing.

Please let me know how to lock these signals from firing.

Thanks.

[douglas.malnati]

douglas.malnati said:

I am, for example, able to block MPSL_TIMESLOT_SIGNAL_TIMER0.

Typo, I meant to say I am able to block MPSL_TIMESLOT_SIGNAL_RADIO.

[Sigurd]

Hi,

MPSL uses ZLI, and it's not possible to disable that.

douglas.malnati said:

So I'm unclear on why an irq_lock() isn't preventing these signals from firing.

This is the expected behavior. See https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/hardware/arch/arm_cortex_m.html?highlight=config_zero_latency_irqs#zero-latency-interrupts

[douglas.malnati]

Hi, thank you for the reply.

I think this is bad practice on the part of Nordic.

The documentation about ZLI states "Zero-latency interrupts are expected to be used to manage hardware events directly."

Clearly MPSL isn't a device driver, it's going to interface with application code/logic and of course, state.  The state keeping is the agonizing part here, because ZLI trashes state.

Even the example use case linked above, from Noridic, has to do gymnastics to escape the consequences of unblockable IRQs (ZLI).  But it only half escapes them.

The irony is the Nordic example case simply offloads interacting with the application to a different blockable IRQ.

I think MPSL should be modified to support using non-ZLI on a session-by-session basis (maybe at the expense of new interrupts having to be allocated by the application or whatever).

I can understand some subsystems might want ZLI, but not all do, and by forcing ZLI on users you're making application code a complete nightmare.

Also the MPSL documentation should clearly state ZLI is being used, and how, and the consequences.

Thanks.