EGU to SWI occasionally missing flags

RE: EGU to SWI occasionally missing flags

bjorn-spockeli — Mon, 25 May 2020 10:24:57 GMT

Ok, glad to hear that you found a workaround 🙂

RE: EGU to SWI occasionally missing flags

Benjamin — Mon, 25 May 2020 07:04:31 GMT

The SWI is only triggered via PPI. When only one timer (which triggers the SWI via PPI) is running, the flags are always set correctly. When more than one timer is running, most of the time, the flags are set correctly, but very occasionally, the flags are missing.

I've not looked more closely at the SWI library to try to figure out could happen if a 2nd IRQ is triggered during the ISR since I have an adequate work-around.

RE: EGU to SWI occasionally missing flags

bjorn-spockeli — Mon, 25 May 2020 06:31:28 GMT

Hi Benjamin,

OK, so the SWI ISR is triggered and executed as often as you are expecting, but if one or more timers trigger the SWI while the SWI ISR is running, then the user flag passed with the pending interrupts are zero.

Looking at the nrfx_swi.c code, it does seem feasible that the

void nrfx_swi_trigger(nrfx_swi_t swi, uint8_t flag_number)
{
    NRFX_ASSERT(swi_is_allocated(swi));

#if NRFX_SWI_EGU_COUNT

    NRF_EGU_Type * p_egu = nrfx_swi_egu_instance_get(swi);
#if (NRFX_SWI_EGU_COUNT < SWI_COUNT)
    if (p_egu == NULL)
    {
        m_swi_flags[swi - NRFX_SWI_EGU_COUNT] |= (1 << flag_number);
        NRFX_IRQ_PENDING_SET(swi_irq_number_get(swi));
    }
    else
#endif // (NRFX_SWI_EGU_COUNT < SWI_COUNT)
    {
        nrf_egu_task_trigger(p_egu,
            nrf_egu_task_trigger_get(p_egu, flag_number));
    }

#else // -> #if !NRFX_SWI_EGU_COUNT

    m_swi_flags[swi - NRFX_SWI_EGU_COUNT] |= (1 << flag_number);
    NRFX_IRQ_PENDING_SET(swi_irq_number_get(swi));

#endif
}

static void swi_irq_handler(nrfx_swi_t swi)
{
#if (NRFX_SWI_FIRST > 0)
    NRFX_ASSERT(swi >= NRFX_SWI_FIRST);
#endif
    NRFX_ASSERT(swi <= NRFX_SWI_LAST);
    nrfx_swi_handler_t handler = m_swi_handlers[swi];
    NRFX_ASSERT(handler != NULL);

    nrfx_swi_flags_t flags = m_swi_flags[swi - NRFX_SWI_EGU_COUNT];
    m_swi_flags[swi - NRFX_SWI_EGU_COUNT] &= ~flags;

    handler(swi, flags);
}

When you're triggering the SWI through PPI and not with the nrfx_swi_trigger() function from SW, then I do not think that the m_swi_flags variable is set. So when the swi_irq_handler is executed, then m_swi_flags could zero. Do you agree?

-Bjørn

RE: EGU to SWI occasionally missing flags

Benjamin — Fri, 22 May 2020 19:43:22 GMT

I dug into this more (and also forgot to update the ticket) and i'm pretty sure what happens is that sometimes a 2nd (or more) SWI IRQ fires while the SWI ISR is running, and when the follow-up ISR is run, the flags value is passed in as 0.

I don't see any missing flags when I only have 1 'channel' enabled, and the frequency of misses seems to increase with the number of channels enabled.

RE: EGU to SWI occasionally missing flags

bjorn-spockeli — Fri, 22 May 2020 12:43:26 GMT

Hi Benjamin,

Apologies for the very late reply.

So if I understand the issue correct, the SWI function is not called as often as you are expecting and the flag value passed with the SWI function is often zero?

Could you try to replace the SWI trigger task with a GPIOTE OUT task that toggles a GPIO? Im just thinking that it would be nice to verify that the COMPARE events are triggering as often as you are expecting them to trigger.

Best regards

Bjørn

RE: EGU to SWI occasionally missing flags

Benjamin — Mon, 20 Apr 2020 23:18:49 GMT

At ~2 MHz, that's on the order of microseconds, not milliseconds.

RE: EGU to SWI occasionally missing flags

bjorn-spockeli — Mon, 20 Apr 2020 19:14:38 GMT

Hi Benjamin,

please note that in the worst case there might be up-to two 16MHz clock cycles delay from an event to the task being triggered, see PPI — Programmable peripheral interconnect

On each PPI channel, the signals are synchronized to the 16 MHz clock, to avoid any internal violation of setup and hold timings. As a consequence, events that are synchronous to the 16 MHz clock will be delayed by one clock period, while other asynchronous events will be delayed by up to one 16 MHz clock period.

Also, If I remember correctly the ARM Cortex M4 has a interrupt entry/exit latency of 12 cycles( the M4 is running at 64MHz). So without accounting for tail chained interrupts, the latency of entering and exiting the ISR is 24 cycles, so the maximum frequency one would be able to enter the ISR would be 2.66 MHz if my math is right. If we take into account tail chained interrupts the latency is 18 cycles, resulting in a maximum frequency of 3.55 MHz.

And then we're not taking into account the code running in the ISR, which needs to be added. So it could be that this all adds up to something in the ms range.

Best regards

Bjørn