Problem with direct interrupt / zero latency interrupt on nRF5340

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

ovrebekk — Tue, 19 Sep 2023 08:09:02 GMT

Hi Michael

That is correct. If you don't really interface with the Zephyr kernel at all from your interrupt there is no need to call ISR_DIRECT_PM().

Best regards
Torbjørn

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

puz_md — Mon, 18 Sep 2023 13:02:58 GMT

Thanks for the detailed reply, Torbjørn. Clearing the event helped.

As far as I know, I have to call ISR_DIRECT_PM() only if I want to trigger the scheduler (e.g. my interrupt triggers some context switch to a higher priority thread). This is not the case in my implementation, so I don't call the macro according to the documentation that I have read. Especially as my interrupt is running at 16 kHz and the system tick is only 1 kHz if I remember correctly

Can you confirm that I don't need ISR_DIRECT_PM() in my scenario and that it is not mandatory to call it in EVERY direct isr implementation?

Also thanks for forwarding the plugin bug to the VSCode team.

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

puz_md — Mon, 18 Sep 2023 12:57:09 GMT

Clearing the PWMPERIODEND event in my interrupt handler was actually what made it work. Thanks for the hint, Turbo J!

I was falsely assuming that the PWM end is just communicated as an event (edge based) to the NVIC to trigger the interrupt bending bit, just like it does when triggering a task (which works fine in the background even without clearing the event bit).

ISR_DIRECT_DECLARE(pwm_isr)
{
    NRF_PWM0->EVENTS_PWMPERIODEND = 0;      // This is needed to reset the pending interrupt and return to the calling context
    m_pwm_interrupt_cnt++;
    return 0;
}

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

ovrebekk — Mon, 18 Sep 2023 12:47:22 GMT

Hi Michael

It is true that you need to clear the event manually in the interrupt handler (clearing the pending flag in the NVIC is not required).

Potentially an interrupt could be triggered by many different events, and the event handler will typically check the status of each event in turn, and clear it if set, before running the associated code.

Secondly, when using the ISR_DIRECT_DECLARE() macro you should also use the ISR_DIRECT_PM() macro at the end of the interrupt handler.

For an example of this please have a look at this interrupt handler from the ESB library.

If you look at the implementation of the radio_irq_handler() function, here, you can see that it checks if the event is enabled and clears it, as described above. It also checks if the event interrupt is enabled, but you can skip this if you are not planning to enable or disable interrupts for the event dynamically.

For the debugger issue, I was able to reproduce this here. For some reason the VSCode debugger doesn't properly interpret the ISER and ICER registers as an array, and they all point to the same register (ISER0).
If you try to read the register in the code, or debug with Ozone, the register values are correct.

I will report this to the VSCode team and ask if they can look into it.

Best regards
Torbjørn

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

puz_md — Mon, 18 Sep 2023 08:02:08 GMT

You mean the PWMPERIODEND event in the pwm module? I could try that...

Is the NVIC state (clear pending interrupt) handled automatically by the macro definition? (If yes, will the pending flag be reset in the header or the footer? Just to be sure what happens in the case of a timeslice overrun of the interrupt code).

And concerning the NVIC screenshot during debug, do you know what's the issue with it? Is this a nRF Connect SDK bug?

RE: Problem with direct interrupt / zero latency interrupt on nRF5340

Turbo J — Fri, 15 Sep 2023 17:34:48 GMT

The isr function must reset the condition that trigerred the interrupt. Otherwise the processor just keeps tail-chanining into the function again.

Your function does not do that, and runs at highest possible priority - so nothing else can preempt it either.